you lost me with that last paragraph, to put it nicely.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.
Thing is - I don't see frameworks solving these problems. I see frameworks doing things like automating directory layouts, adding some magic to reduce typing, handling request dispatching, etc.
I see libraries solving these problems. I use Cheetah too, and am grateful for its #filter Websafe. I use Markdown - it has the same javascript: bug as Reddit, but at least I or someone else can submit a patch to Markdown and have it fix every site using Markdown and not just my own. I use the parameter replacement available within DBAPI to avoid SQL injection attacks.
I don't like software that tries to solve all my problems, because it inevitably mis-guesses and solves about 80% of them, making the remaining 20% pretty hard in the process. I like software that tries to solve one of my problems and solve it well, because then I can swap in the best solution for the job. Fortunately, the newer Python frameworks (Pylons?) are going down that road, but I didn't see much advantage in using Pylons over using DBAPI + Cheetah + Prototype + Web.py dispatching.
Can you explain to me how unsexy problems like browser incompatibilities (yes a major pain) lie anywhere within the scope of webpy? Those seem to lie within the scope of the templating system and js library that you choose.
A larger, more complex framework does present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.
Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.