"I am not saying that there can't be other solutions, I am saying that our current solutions suck."
What? Zope sucks? Quixote sucks? I'm sure the developers and communities of those and other solutions would certainly feel encouraged to hear that kind of judgement fall on their hard work (and success, too).
"If any of our solutions were as good as Rails, they would have a dominant user base in the Python community. I really believe that!"
Well, aside from the fact that any incursion into the Rails site to see what the fuss is about tends to set off my anti-hype alarms (even more so than the JBoss site, circa 2001), and even when I've hit the "master alarm" I just get presented with various JSP-like endeavours which are, after the "scaffolding" is set up (to borrow the Rails terminology), arguably mostly as easy in a JSP environment (albeit without the transparent SQL-based persistence supposedly provided in Rails, and yes, a "to do" list tutorial isn't going to show off the power of Rails, even if the only Rails applications seem to be "to do" list managers, anyway), I must regard the framework domination claim somewhat skeptically.
Ages ago (ie. 1997) solutions like Bobo provided a clearly better means of developing Web applications than just using cgi.py. What then happened was that Bobo grew into being Zope, and that many developers did indeed follow that path, thus forming the Zope and Plone communities which seem in many respects to be disjoint from what is now considered to be the mainstream Python community - in a way, a dominant solution did emerge, but only as a parallel community. Meanwhile, in the wider Python community and inspired by various other Web programming paradigms, a number of frameworks emerged and matured to produce the ecosystem that you see today. Certainly, Quixote has a certain number of advocates, but probably nothing like the number of the solution that is said to have inspired it: Zope.
"I think its really selfish to hold onto one's own framework if presented with the option to unify."
You ignore the fact that most frameworks are designed to address real situations and quite possibly function adequately, even optimally, for their developers. Is it selfish for someone not to abandon a framework because it is used in a production environment and that such abandonment would force them to migrate their existing applications for free just for those applications to function more or less as they did before? Sure, you get eventual benefits from your application suddenly using code that someone else is maintaining, but then there's always the temptation to open source your own framework and to try and get the maintenance advantages of a larger development community whilst having everyone else migrating their applications instead. (I suppose that this might explain why so many competing frameworks emerge, even though they often resemble one another - it's just the "selfishness" of not holding onto one's own framework...)
"Lets make the WSGI just that -- a way out. But, we shouldn't try to make it the Servlet's of the Python world!"
Well, WSGI doesn't really address anything other than a very basic standardised environment; not that there isn't merit in addressing that area, but I was disappointed that people were happy with just settling for that, and somewhat disturbed that for many people WSGI is just something to believe in whose existence acts as an excuse for not getting to grips with the harder issues.
Personally, I don't care about the WSGI level - I'd rather examine the higher-level concepts which applications use directly to behave in the ways that they do. After using Webware a fair amount, I wanted to experiment with other frameworks if only to avoid various pitfalls and issues that Webware had, but I didn't want to rewrite my framework and applications to make them run on Twisted (for example). In the end, I created WebStack to enable this whilst papering over some of the bizarre behaviour of various frameworks. For me, WebStack "scratches my itch" because I can now ignore framework issues and concentrate on actual applications.
So for me the framework wars are over. I don't care about the "distinctive" things that many frameworks promote (ie. the special template language or the URL dispatching scheme that should in any case really be determined by the application being written) - I just want a sane API which mostly returns request parameters, streams, sessions, cookies and so on and which doesn't force me to have to reinvent several wheels in every application I write, just because of some misguided minimalist agenda on the part of the framework designer. And if I want my application to appear at http://mysite/zope/folder/myapp even after prototyping it on BaseHTTPServer, then so much the better!
I agree with you in part Paul. And I shouldn't have used the word "suck" to describe any of the existing frameworks, as they still beat the pants off of anything available for PHP or Perl. The people who work on those frameworks can and should be proud of them. But, I do believe that they don't stack up to Rails. I agree that their hype machine is running at full steam, and that is pretty obnoxious. But, its hard to deny the traction they are getting.
And, no, they aren't doing anything all that impressive technically. People have been writing bits and pieces of the Rails framework in Python for years and years. But, they aren't putting all the pieces together in a simple way and working together to create a singular foundation. Rails is doing it well, doing it all, documenting it, and getting it publicized. I just wish that we had something comparable.
Personally, I don't care about the WSGI level - I'd rather examine the higher-level concepts which applications use directly to behave in the ways that they do.
That's what my talk at PyCon was about, and I want to re-express all those same ideas here as articles. WSGIKit is an architecture that uses WSGI as the way to pull together those higher-level concepts -- it's using WSGI as much more than a generic way to connect to a server. If all WSGI did was connect apps to server, it would be useful but indeed quite boring -- but WSGI is really a sneaky way of creating a standard request and response object, and a pattern for providing a stack of filters. And that is a big deal, even if it isn't an end in itself.
> What, ZOPE sucks?
No, wouldn't say so. However:
I'm a python enthusiast, but up to now, I wasn't able to find ANY python web development framework comparable to J2EE with respect to the learning curve.
I took some time and tried several python solutions:
CGIHTTPServer and low-level from the standard modules It is fine as a sample and easy to learn, but far from being production based. It took me days to find out how to write a multi-threaded server. I could help very much if there wasn't only the 5-line sample code, but also a multi-threaded server program that at least works fast enough for in-house use.
And, even worse, though the HTTPServer and cgtib are both standard modules, there seems to be no easy way or example of how to actually let them work together.
What we need is at least a basic standard solution using a multi-threaded CGI server together with the cgitb routines.
twisted Fine ideas, very promising, but needs a complete new way of development. I read the docco several hours. It is just too different from everything else, so it is ruled out. You'll never set up some hello world examples after 2 hours like with JSP.
mod_python The best standard solution, I think, but: I agree with some others here. The main problem with mod_python is the lack of a good Apache 1.3 version. For example, we are using Oracle Application Servers for production (based on Apache 1.3), so mod_python is out of the race automatically.
ZOPE Zope is a world of it's own. Just like twisted, there's too much to learn for a quick start. And with all those different template languages, it's confusing.
In my work, I'm forced to use J2EE. I don't really like it, because * I have to use Java (better than C, but ways behind Python) * Development is SOOOO slow * J2EE is a very complex world now.
But: it is very easy to start with. Every java programmer can write a Hello World JSP and test it within a few hours. The difficulties only follow later, as soon as things like session handling, DB connections, error handling, reliability etc are considered. But at that time, the devloper is already convinced that - in principle - he can build a solution with J2EE.
A python solution should make it easy to start learning from scratch, that's the pythonic way to go! (just like JSP/J2EE does...). And it should be in the standard module library.# Henning von Bargen
"twisted Fine ideas, very promising, but needs a complete new way of development. I read the docco several hours. It is just too different from everything else, so it is ruled out. You'll never set up some hello world examples after 2 hours like with JSP."
The web is only a small part of twisted. Or did you mean Nevow? I think you could pick of the basics of Nevow very quickly without knowing much about twisted, though you do eventually need to pick up some twisted basics like deferreds, adapters, realms, etc. to be fully proficient with it. The main problem with Nevow as an application framework is the lack of integration with an ORM and the immaturity of some parts (e.g. formless needs a lot of work to be useful for more than simple forms.)