The Python world is ridden with frameworks, microframeworks, metaframeworks and their likes. They are often very clever things, but more often than not they are a tool of despair.
A very peculiar thing about Python web frameworkish things is that there are so many of them. There's cherrypy (in its various API redesigns), fapws, gunicorn, bottle and flask, paste, werkzeug and flup, tornado, pylons, turbogears 1 and 2, django, repoze who, what and whatnot, all the myriad of rendering engines and buffet as a metathing on top of them, diesel, twisted, and I apologise if I don't spend my day listing and hyperlinking them all, I hope I made my point.
Frameworks are supposed to standardise some aspects of programming; the nice thing about standards is that there are so many of them to choose from, and they all suck, so I'll make my own.
But wasn't Python supposed to be the world of TIOOWTDI?
Ok, everbody knows it isn't. Just in the standard library there are 2 implementations of pickle and 2 urllibs. But people like the TIOOWTDI idea.
I believe the reason people like the TIOOWTDI idea is because it creates a framework. It standardises some aspects of programming, and defines building blocks that guarantee that people doing similar jobs will be using similar sets of components.
Let's take for example the datetime module in the standard library. It is an embarassing example of a [[badly designed module|2009/debian/using-python-datetime]], so embarassing that the standard library documentation continuously fails to document its fundamental design flaws and common work-arounds hoping that noone notices them, but as a consequence each poor soul starting to use it for nontrivial things has to google for hours in despair to rediscover in how many ways it's broken.
But still, datetime works as a structure to hold those values that make a date, time, or full UTC timestamp. For that job it's become the standard, and as such it's an important component of the Python TIOOWTDI framework: one can use it to exchange datetimes among different libraries: for example ORMs are using it instead of rolling their own, which makes database programming so much easier when date/time is involved.
Even if the implementation is far from perfect, once we apply TIOOWTDI to dates and timestamps, python code from different authors can exchange dates without worries. This is much better than having 3 different superior datetime libraries and having to convert date objects from one to another when passing values from a web form to an ORM.
There is an often overlooked Python framework. The Pyton framework. It's called TIOOWTDI.
All the micro-mini-midi-maxi-meta-frameworks that people scatter around, are, or should be, just experiments, proofs of concept, competing ideas waiting to be distilled in The Only One Way, bringing the Python experience one step forward.
What is unfortunate is that this last distillation thing happens so rarely that people get used to the idea of having to use proof of concept code to get things done.
Update:
this post apparently wasn't very clear, so here is some clarification:
- that python, plus the idea of TIOOWTDI, in fact generate a framework, the framework;
- that framework currently includes very little web stuff;
- the web stuff is currently shipped in countless prototypes and proof of concept things;
- something from all the prototypes people develop ought to be brought into the TIOOWTDI "framework";
- otherwise people get used (or worse, forced) to use proof of concept throwaway code to get their job done.