I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming
to the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way.
I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.
I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.