Helo Ian,
Ian Bicking a écrit :
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.
AFAIK, this thread has never intented to be technical nor to discuss
design of we framework. This thread was about "I don't like this or that
so I do this and that." Anyway...
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.
Being positive about your own framework/product and silent about others
is pretty much the same as being negative overall since you do not say
"yeah well my framework does not do that but framework X does it prtty
cool and we might want to sgare our ideas..."
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.
er... it's what happens in the Python world most of the time :/
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.
Good point and you are one of the first to actuallt state that publicly :)
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.
Interestingly CP developers has never really made such a strong
statement as becoming the "foundation of Python on the web". We have
said instead that we would only focus at being low level and with a
limited scope. We also said that we would try not to be too restrictive
in the way we would work to let others building their framework on CP.
TG is the first (public one) to try that on a large scale, it's normal
some people find limits to the way we have designed CP.
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.
Agan Ian, we haven't said we were against, we have said two things:
1. As far as we are con concerned, this is not something we can
realisticly do in the current branch
2. We have agreed to do everything we could to integrate your ideas in
CP 3 as long as it would not mean people would be obliged to use Paste
(or anything else) to run their applications. WSGI support is a must
have but does not mean it will be the only way to setup CP applications.
I guess that shows we are open to your ideas right?
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.
Of course and I do agree with you (even though some might argue the more
you generalize the less "usable"/bloated you become...) but things will
happen, there is no need to rush :)
- Sylvain
