Okay, first to respond to Glyph's statements:
"""I don't disagree with Ian's diagnosis of the problem (although it's not terribly relevant to me personally), but I will disagree with this particular prescription for it. I can understand being frustrated with the proliferation of web frameworks, but let's face it: there is no way you are going to be able to convince anyone to give up on their pet framework to work on someone else's."""
I am not saying that anyone has to give up their old software. And Ian's suggestion for the WSGI as a "way out" is a good one. However, I do think its reasonable to centralize around one solution. I am not saying that there can't be other solutions, I am saying that our current solutions suck. 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! I don't even care if we start from an existing base, as long as we get somewhere!
"""I see a lot of people in the Python web community complaining about proliferation of frameworks. I don't see anyone at all standing up and saying "My web framework X is unnecessary, I will abandon it and spend my web-framework development time working on web framework Y instead.""""
Well, I don't have a framework that I have written that is out in the world. However, if I did, I would be willing to give it up or allow it to become the new central framework. I think its really selfish to hold onto one's own framework if presented with the option to unify. Let's be honest, there are probably only 3 or 4 different Python web frameworks with any traction whatsoever. This adds up to somewhere between 5-10 people (likely) that actually have control of these frameworks. I see no reason why 5-10 people can't come together and work as a group to improve the obviously broken situation we are in now. What we currently have is good for noone: especially the Python community.
"""Let's focus on what is going to make web frameworks seamless to use. Personally I think that "web programming" is a red herring and the problems with Python are basic platform deployment issues: for example, the lack of a packaging system makes the simplest task in web programming - downloading and setting up a framework - unnecessarily difficult."""
Wow. I really disagree. This might make us slightly more popular, but it certainly wouldn't make us better. You are copying Java. We need Servlets, JARs, and a few specifications, and we will be good! Ever developed Java web applications? It sucks compared to Rails. You are using the wrong benchmark.
"""For those of you that are going to heed Ian's call to arms, please consider productive suggestions that people can follow. If we're not each going to give up our individual toolkits, let's at least agree on the featureset that would make each of them really attractive to new people coming to the Python web space."""
Why wouldn't we give up our individual toolkits? You can't win if you aren't willing to change. You are saying the best we can do is stagnate. I totally disagree.
"""For example, Alex Levy suggests that the problem is documentation: http://mesozoic.geecs.org/cogito/archives/000152.html"""
Insufficient solutions with good documentation are still insufficient. Show me something that is as unified, cohesive, and useful as Rails, and is just missing documentation. It doesn't exist.
Now, for Ian's response:
"""Well, I personally have resisted the urge to develop a new framework (an urge I've felt many times over the years), and I actually am willing to give up my framework of choice for more conformity. But I can't abandon my framework (and I can't expect anyone else to do so either) -- other people have trusted my opinion and choice over the years, and it would be irresponsible of me to abandon them and those applications I've developed. Which is a bind a lot of us have probably been in. That's one of the things I see in WSGI, is a path out -- a way to support the old apps and consolidate and improve the new apps, without being bogged down in abandoned frameworks and out of date setups."""
I agree with you here Ian. Lets make the WSGI just that -- a way out. But, we shouldn't try to make it the Servlet's of the Python world!
"""Talking to people at PyCon, I don't think I'm altogether unusual. First, there's a lot of people with homegrown frameworks, and from what I can tell this describes most of them -- they are dissatisfied but trapped by their own legacy. But even beyond that there's hope that open source frameworks can consolidate. If we can phrase one framework in terms of another there's the opportunity for the lesser frameworks to melt away, to create a layered environment instead of competing full-featured stacks (well, they are all actually partially-featured stacks)."""
Thats very true, and I think you are on to something here. Please, keep preaching it. Maybe you could organize some "summit of web frameworks" or something :) Get the authors of the disparate solutions together, and come up with something better.
"""As to Rails: I agree that it's a challenge and a competitor, but it's not a model. People have been working on Rails-like things in Python for a long time, with various successes and failures. But Python's flaw isn't that we don't have any interesting frameworks or interesting MVC systems. Python simply isn't at the same place Ruby is. We have to fix our specific problems, not immitate someone else."""
I don't think we need to clone Rails in Python. Rails is a very ruby-like solution, and there are certainly things I dislike about it. I am not saying we need to model it by copying it: I am saying that we need to model its principles. Its a VERY RUBY, tightly integrated, complete, simple, and fully-functional framework for building web applications from the database all the way up to the top. We need to create a HIGHLY PYTHONIC, tightly integrated, complete, simple, and fully-functional framework as well. It doesn't have to look anything like Rails, but that is our competition. That is our target.
I am not arguing that we need to create an imitator: but we do have to compete on the same level of simplicity and ease of use. PHP and Perl were wildly successful web application languages for some of the same reasons as Rails: simple to install, simple to understand, and documented copiously.
Why do people aim so low?
"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.)