Registered: Jan, 2006
Re: Please Teach me Web Frameworks for Python!
Posted: Jan 27, 2006 2:23 PM
If re-use is important, WSGI should definitely be on your mind. Almost every framework (if not all) now have WSGI support in some form or another. Usually this means they went to the minimum effort to support a WSGI call to their application, which in their usage scenarios is the most that will ever occur. They still assume you would never run anything other than their framework, and their frameworks applications.
First, the framework myself and James Gardner have created is called Pylons (http://pylons.groovie.org/), and is close to a 0.8 release. It is however used in at least one large production scenario now. Pylons is mainly Myghty, with a custom Resolver, full Paste and WSGI integration, and defaults that will likely work for the vast majority of people. As such, the code base is quite small, building on the reliability of Myghty's code.
Pylons fully exploits the power of WSGI, more so than any of the other "full-stack" frameworks out there. When Ian Bicking put out the very cool and extremely useful AJAX webapp debugger (http://blog.ianbicking.org/ajaxy-exception-catching.html), it was merely a few minutes of effort to slot it into place for use in Pylons.
People have said that being able to mix things, rather than writing it all yourself will lead to a 'frankenweb'. I think that's a load of crap, especially with a language like Python which makes it so trivial to use multiple libraries in a cohesive bundle. Pylons utilizes re-use as much as possible, and pulls it together in what I (of course) would consider a very compelling package.
For your list of things you want,
1) Pylons uses Paste (thus flup). You can run your webapp stand-along, with Fast CGI, SCGI, or AJP. All with merely a toggle of one line in a config file.
Pylons uses middleware to catch exceptions, in development mode you get the powerful AJAX debugger to interactively explore what went wrong. In Production mode it will first try and call your webapp's error handler for a nice message, if even that fails it falls back to a static 500 page and will of course email you the full traceback.
2) Pylons, as a super-set of Myghty, provides powerful templating capabilities and a component methodology that maximizes re-use of templates. It has a concept few other template engines have, called multiple component root inheritance, which lets you setup re-usable components. On top of that, every component has powerful caching abilities, so you can cache specific sections of a page, function responses, or the entire page. There's good reasons that Amazon.com, Salon.com and other major companies used Mason (Myghty started as a direct port)
3) Myghty handles all the cookies, sessions, etc. and has been very robust.
4) Form parsing is handled by Ian Bicking's excellent FormEncode package, that makes it easy to ensure the form is valid and coerce form values to the Python types you wanted. (TurboGears also uses this). Myghty handles basic query arg parsing.
5) For URL dispatch, the Routes (http://routes.groovie.org/) package I wrote is used. This allows for flexibility of URL's matching Django, though in what I'd consider a slightly easier way. It also provides powerful URL generation throughout the web application.
For ORM, Pylons doesn't strictly dictate what you should use. It provides some defaults to make it easy to get started with SQLObject if you choose, and we have a few people using the powerful SQLAlchemy package as well.
Since the entire setup utilizes WSGI and middleware, its very easy to get in and change how you want your webapp to function should any of the defaults not suit you. If you want regexp based matching, Myghty provides that and it can be used easily as well.
As I mentioned at the top how these things divide, thought I'd clarify how I'm hoping to avoid that. Anytime a package would stand alone, it does so. Pylons originally had a batch of helper functions ported from Rails. They're useful outside of Pylons though, so we spun them off into their own package where they're now being used by people using other frameworks. We utilize WSGI middleware, and if something would work well in that layer, we put it there so again, more people can use it. So far, the first thing I put into middleware was an OpenID authentication system, which joined Clark Evans middleware that lets you do Digest, Basic, and CAS authentication.
By using WSGI, you can easily plug-in middleware that takes care of a lot of hassles for you, and you aren't bound to a framework. The argument I hear for frameworks including tons of stuff (a toolbox, an admin interface, etc.) is that they're more usable if its all packaged together. Python is powerful enough that this doesn't need to be true.
Take the useful Catwalk program (small webapp for exploring your database through SQLObject), here's what Ian's proposed Routes based integration would look like:
Is that so bad? Imagine being able to go and put the Django admin interface under /admin/ with just one more line. Ah yes, people will scream, but then they won't have a reason to use your framework. Or perhaps they'll complain about the usability of it.
Anyways, Pylons is about maximizing re-use, this means you can use Pylons applications in other fully WSGI capable frameworks, in addition to using other WSGI apps in Pylons. It makes it easy to re-use applications, and create new ones. As frameworks more fully utilize WSGI, the differences between the frameworks will shrink and the useful things; an admin interface or model browser will be usable by anyone.
Whether you choose Aquarium, Django, Myghty, Pylons, Quixote, Snakelets, Skunkweb, eventually great things written in any of them will be as re-usable (I hope). Pylons mainly just does the somewhat daunting task of streamlining the configuration of these things into a usable system that attempts to maximize ones existing knowledge of Python with a configuration that makes it easy to change around middleware to suit your task.