Hello folks,
To be honest, I'm a bit fed up at so much moaning about which or which
is better. I started to use CherryPy for three main reasons:
1. It didn't come into my way for what I wanted to do while having a
nice API
2. I had fun with it because its community was small enough to react
swiftly without too much burden
3. Its community and Remi were very friendly!
The third point might actually be the most important to me. Anyway, for
the last few month CherryPy has been much more under the spotlights
thanks to TurboGears. It's good because it has pushed us to work even
better but at the same time we have lost part of our flexibility because
we have to take care of TG itself as well.
So I'm quite annoyed at people moaning about what CP does bad because
they don't seem to realise that it is not an easy task now to move
things in a way or the other and also that CP is not a TG project. We
have our own goals that at some point might be too far away from Kevin's
plans. That's OK and I'm cool with it. However I have the feeling we
have spent more time lately on discussing things rather than going
anywhere. This is NO fun! Of course we need to discuss, plan and design
but we can't do that and break our current project at the same time.
It's very interesting to se how other projects do this and that but I do
believe people who say "let's use that piece and that other piece" don't
realise that once in the TG project they will loose part of their
freedom just as we did because implicitely they will commit into
something bigger than they had first planned.
Let's bring paste, mighty session, routes or what have you all together
and I bet in a few month time we will see new people coming in to
complain about them.
Look how SQLObject and Kid have been treated lately, so many people just
complained they were bloated with bugs or instead just said "hey let's
drop Kid and use Cheetah because it's better"... what does that mean to
join a project and do such statements?. I do prefer XSLT but I didn't
come and moan at Kevin's choice to use Kid.
On the other hand, I believe this is the success price TG sub-projects
have to pay for being part of such a great adventure :)
CherryPy can't go faster than it goes now because let's be honest there
are only 3 to 5 regular developers on it and it is not enough. I do
wonder then why people don't join much? Well I suppose it's because they
have other things on their agenda, guess what, same here ;) We also have
other projects that we need to take care of because at the end of the
day we get our money from those and not from CherryPy. I wish I could be
paid for working only on it but this is not the case. CherryPy is a
project I've been enjoying for a while now and I have plenty of ideas
for CP 3 but I can't stop sleeping, can I?
So to be fair, I don't care much whether RhubarbTart replaces CherryPy
because I'll still be enjoying CherryPy and that's what matters to me. I
wouldn't want to be at Kevin's place right now :)
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!
This is fairly sad. Therefore if the community here pushes for a
solution that has a better WSGI and paste handling, I don't care because
I want TG to succeed. If it means to leave CherryPy aside, I don't mind
either. But remember that I wouldn't be surprised that by the end of the
summer you end up changing again, and again, and again...
I might sound bitter but this is not the case. It's just that we have
said over and over that we had heard your wish list but we have said
that we would not be able to make it before CP 3. However many people
still complain at how CP does things, fine but what can we do? We won't
screw our users in order to satisfy others. Some people have been
following us for a long time now and we do respect their trust. So
either be patient or as the RhubarbTart has cleverly done, do it yourself :)
Anyway, for now enjoy your pie whichever it is :)
- Sylvain
Bob Ippolito a écrit :
On Jan 30, 2006, at 2:25 PM, Ian Bicking wrote:
Kevin Dangoor wrote:
Here's my philosophy on stuff like this: I aim for TurboGears to be
best-of-breed. The definition of "best-of-breed" will change over
time. (It'll also vary from person to person, but there's not much I
can do about that.) As "the best" changes, I'd like to see TurboGears
change with it. Of course, changes need to have reasonable migration
paths and all of that, which is the primary limiting factor. But, the
bigger the win, the easier it is to justify a slightly more painful
transition.
...
* Filters. CP-style filters could be implemented in RhubarbTart, but
I'd rather just not. The filters in TG could be reworked or have
extra interfaces to be phrased as WSGI middleware. I think the
actual application-facing interface to things like Identity don't
need to be changed, so this might not be an issue. Since TG uses
decorators more than filters (for app-visible APIs), I think this is
mostly OK as-is.
In my experience, filters are a bad API anyway. Every time I've ever
wanted to use a filter, it was for a particular URL, which isn't
really supported without lots of jiggering.
-bob
