Huh... this reply became rather tangential, and more about vague design issues than anything... but so it goes. But I'm also happy (and it would probably be more constructive) to bring this back to concrete design issues.
Sylvain Hellegouarch wrote:
Look at the replies Guido received from his post on Python web framework. A bunch of people saying "mine is better" "no it's mine" "forget it, mine da rules!"... I mean come on! More than the state of the web field in Python, this showed how people don't listen to each other. They just push for their own solution and screw the others!
I really didn't get that feeling from the thread. There was some back-and-forth about Django templates, and a little about their models. That mostly came from Guido's initial criticisms, not criticisms in the comments. Altogether I think people were fairly positive about their own frameworks, and mostly silent about other people's. Though I suppose as a result there weren't as many useful *comparisons* as there could be, but that's mostly because people don't want to criticise other people's work. Frankly if it had degraded into a big bitch-fest where everyone tore apart each other's work, that would probably be more interesting to read and more helpful. Unless people just get defensive and polarized.
We can cooperate and refactor in response to these discussions (especially discussions with substantive comparisons and criticisms). But we need to know what each other are doing, what the advantages are of different approaches, and understand what barriers exist, and try to remove those barriers.
One major barrier I see is the issue of competing "ownership" of the environment. Some systems and frameworks want to have control, but only one such system can have control at a time, and so people have to choose camps, and sharing becomes more difficult. Notable dominating frameworks are Zope (largely due to its security system) and Twisted (with its reactor); there are escape hatches in both, but you are mostly in or out. But to a lesser degree other frameworks want ownership too. This is at the core of my problems with CherryPy. This isn't a problem that CherryPy developers see, because they are comfortable owning the process.
If you (the collective "you") want CherryPy to be a foundation for "Python on the web" or for subframeworks or for whatever, it requires a bit more of a conscious effort than just "works for me", which has been the primary retort for any desire to support Paste. That CP has a limited scope helps reuse, but is not by any means sufficient. In Webware there was the same self-impression that it was a suitable basis for building frameworks, but just saying it is so doesn't make it so, and satisfying the desires of current users might not do anything for expanding the potential pool of users.
CP could release control, but that doesn't happen by magic, and it's hard to do from the outside. If it was just a matter of me saying "I want control, give it over" then eh, it's just going to be a back-and-forth as different pieces become the "base". If TG just traded one master for another, then maybe it would just be a matter of successive rewrites and switches all the time and I don't think it would be worth considering.
But I'm not asking for control to be given to me, and RhubarbTart isn't asking for control either -- but that simplicity comes at the cost of many failed attempts at simplicity that have been thrown away in the process. What I want -- because I believe it makes for a more robust foundation for Python web programming in general -- is for control to be relinquished to anyone who wants to take control, and to allow that control to be passed around. Making TurboGears or CherryPy work with Paste isn't about Paste taking over, it's about CP giving up some control to some unknown entity. That might be a piece of Paste (like a piece of middleware), or something someone else develops, or something the application author does on their own. There's a ton of useful and interesting ways to use this lack of ownership in dynamic ways, to generalize applications much more than is typical in the current batch of applications, without having to build every bit of generalization in from the start. Some of the things allowed are redundant with things CP already does (e.g., with filters); but there really is more to it than that.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
