One aspect of WSGI is that it's a protocol, not an API, so it leaves off things like nice methods and conveniences. It's really quite easy to build such conveniences, but it is "left to the reader" as far as the spec is concerned. Building a request object out of the WSGI request environ is just a matter of constructing a very thin facade. And it's not all bad -- there are a couple different, valid ways to build that facade. And if you have a legacy API you want to support, I think wrapping the WSGI request environ is easier than wrapping someone else's higher-level API. To me WSGI is aesthetically bare, not ugly.

That said, I'd be happy to see more standards. I've been trying to push for more casual standards of stuff in the WSGI environment on Web-SIG, but at this point there's only on the order 1-2 consuming projects for any particular interface, so I guess it's not surprising the motivation isn't there yet. There's also lots of possible standards related to web stuff that doesn't relate to WSGI at all -- like pluggable templating languages or session backends. Actual APIs would be possible too, like a request object, but I feel like we need to clarify the role of the request. I, for instance, have a very different idea of what a request object is compared to CherryPy or Zope -- I just don't see how traversal should be part of it. And I think standardizing anything related to traversal is a bad idea, because that is not a solved problem in the slightest. Not dealing with URL resolution is one of WSGI's big features.

The profiles you mention fits very much with what Paste is trying to help develop. I've called it "branding" sometimes, but same idea -- you identify a set of pieces that work well together, for some segment of people. Making that into a "framework" comparible with what people expect from a framework can just mean presenting some cohesive documentation, some file layouts that get people started quickly, and things like mailing lists that let people share their knowledge. It's more story than code.

At the same time, a decoupled architecture means you can move out of the framework without being forced to abandon it. If you look closely at a framework like Pylons or RhubarbTart, it wouldn't be that hard for them to remove the requirement on Paste. Or, more simply, remove bits and pieces -- e.g., use a different session handler, or a different URL parser (well, they mostly already do that), or a different scaffolding generator, or a different configuration loader.

Having spent a great deal of time evaluating various frameworks and libraries that purport to make our lives as developers easier I can't help but notice that the whole shooting match has turned into an acronym encrusted pile of twisted code with wildlife terminology thrown in for good measure.

All programming languages have at their core a Compute Understood Notation Translator (acronym omitted) that translates what we want into what we or our end users need. Frameworks and libraries built on and for these languages are supposed to make our job easier  but don't in the majority of cases. They all come with their own set of solutions for the common problems faced by webapp and/or guiapp developers. There's simply too much to learn to truly be productive with any of them. Don't get me started on documentation. The only decent attribute these packages have in common is that they are written in Python which at least makes them readable. Although some have gone out of their way to make even Python hard to read. Fill in you own names here...

The frameworks that don't get in your way generally don't have the low level solutions for authentication, persistence et al. The ones that have these facilities implement them in fairly non-pythonic ways that make the learning an even steeper climb or make them so entwined with the rest of the framework that they are hard to replace with something better or preexisting.

As to templates, well, how many ways are there to make a web page template hard to read  pick a template solution and add it to the list. If the template system has code fragments I know I wouldn't feel comfortable handing it to a CSS designer. Heck - I can hardly read some of them and I can at least decipher where the code stops and the HTML starts.

Having read all the responses to your original post there were a couple of systems that had escaped my notice. One in particular  Pylons - was recommended by one of the posters who I happen to know. I also know quite a bit about the application he's working on. His application has all the requirements you originally stated and then some  so take a look  if it suits him it may suit you. I too have started looking at it as I have a similar itch to scratch. I managed to get it running quite quickly. The code is quite easy to read and if all else fails I'm sure there's a cream or suppository available from the pharmacy.

Good luck with your search and I look forward to reading more of your thoughts once you've done the download/dependency/dochunt shuffle.

The reason that I chose Kid for TurboGears is that *most* of the templates in a web app are indeed generating HTML (or XML) these days. An attribute language like Kid helps to ensure that you get valid output. Kid, in particular, lets you use standard Python bits for "if" and "for" and also provides easy interpolation using ${}.

You *can* generate plain text with Kid, but I agree that it's not the best language for non-HTML/XML formats. That's part of the reason TurboGears accepts different template engines as plugins.

My hope is that this will help people understand what a WSGI-based framework can look like on the inside, and how it allows such significant decoupling and reuse. And does so while still being a rather mechanical and concrete, without any deep new ideas. Maybe some people will be inspired to write their own frameworks from it, and that's cool -- I have no problem with that. But the real goal is to help people feel comfortable with how these frameworks work, and to feel comfortable about how you can compose applications and extend the applications with WSGI middleware.

Having written the same application in both TurboGears and Django my advice is go for Django. Yes, it comes with its own templating and authentication but you don't have to use them Django was written by a few people with a common vision - it all fits together well. It makes sense. TurboGears is a combination of projects and visions - it feels like a mess to me.

This post sounds like it was written by someone who is very confused. It may be helpful in such cases if we drag in some old and worn out analogy, to try and clarify the issue.

Today, I'll go with the much dreaded car analogy (like, how many times have you already heard the car analogy applied to different problem areas?)

If I go out and buy a regular car (like a family sedan), I'll know pretty much what I can expect when using it. It is of no use if at that time if I start waffling: "But, but, what if I want to drive it off road? What if I want to drive it up two flights of stairs? What if I want to go to a safari in it?" Etc.

The harsh reality is, the family sedan can't do these things. And if that's the case, why am I even considering buying it?

Well, for various reasons. To begin with, the price is right, the gas mileage may be right, it's comfortable, it fits my lifestyle.

And, last but not least, how likely am I to drive my car up two flights of stairs anyway?

Same is with the frameworks. We choose them for the price, for the comfort level, for the style. We don't choose them based on the fact that they can accomplish some exceptional, but rarely used and rarely needed thing.

Alex, please lets not get into a RoR vs python debate again. Save it for your vancouver "ruby on rails" talk. The poster is well known for his design skills. Personally I wish all LAMP (RoR) developers could agree on one basic architecture. M$ is going to make it incredibly easy to develop internet applications by drop in web services. Each component they offer for their .NET will be one more application it will be tough for a LAMP developer to get paid for. I don't hope that google releases office software, I hope they buy salesforce.com and make it easy to develop ASP business applications before M$ does!

Allow me to digress under the assumption that a "web framework" and a "web application framework" are different beasts: the former meant for serving pages and simple text-based data transactions, the latter for doing things like google maps and beyond. The sooner we all realize the importance of this distinction, the better.

The reason there is no good web application framework (in any language) is an infrastructure issue. HTTP was, of course, originally designed to transfer text, period. Everything it is capable of doing today is just a hack; some are clever, some are ugly. AJAX is like folding a web page origami-style into a Lego brick; suitable for lightweight work, but not so good for building a castle. The web browser as a client has the advantage of ubiquity and the disadvantage of limited purpose: page viewing. Zope, TurboGears, Rails and the other frameworks all have too many facets to be categorized as an elegant solution for web apps. In my opinion, writing a web app should be no more difficult than writing an equivalent desktop app: one syntax, one std lib (but many other libs to choose from), put the resulting package in a path and it works.

To make the next kind of web applications--something more than a limited-dimensional view into a database--a different infrastructure is necessary. We continue to use a web browser talking to a web server to find your way to the app, but then we launch into something more that will allow an MVC style app with the model maintained on the server, the view projected to the client and the control information happily traveling as needed across the connection.

Just as electricity and water arrive at the house through different infrastructures, so too should document services and general applications arrive to the computer.

> I want libraries. It's fine if a framework provides one of each, which would be a standard library.

I agree with you 100%. The great thing about the standard library is that - unlike some parts of common Java libraries - it isn't a framework, it doesn't force your app into complete dependence on the library.

If there's something a Python standard library module does badly (and let's face it there are a few places where that's the case) there's absolutely nothing stopping one writing an alternative replacement that works completely differently. We have no one standard web framework, but that also means we're not locked into the mistakes that the Servlet API made and was never able to fix.

Judging by the current glut of frameworks some people do indeed like to be Told What To Do with their applications. That's fine for them, but I prefer choosing independent libraries by different authors for my form-submission-reading, templating, database/ORM and whatever other needs. There's no need to impose the choice of a standard framework on everyone, even if there was a single framework that could gather that kind of momentum.

The remaining problem is simply the historical lack of a standard for authoring apps that will run on any server - other than CGI which is hampered by its poor performance and still doesn't run over some servers. WSGI addresses this in an encouragingly minimal way IMO.

A packaging standard built on top of it (to ease application deployment) would be welcome too, as would some smoothing of the way various servers mangle HTTP_AUTHORIZATION. But I don't want to see 'from standardlibrary import WebApp; class MyApp(WebApp)'.

AC wrote:> A packaging standard built on top of it (to ease> application deployment) would be welcome too, as would> some smoothing of the way various servers mangle> HTTP_AUTHORIZATION. But I don't want to see 'from> standardlibrary import WebApp; class MyApp(WebApp)'.

I'm not pushing an agenda here, but I'd be interested to know what the objection is to doing the above at a certain level in the Web application stack, given that you're going to need some kind of integration with an external "event loop" in a way that doesn't assume a CGI-style main program invocation. Consider many/most GUI toolkits: you usually have to instantiate some kind of application class to integrate with the event loop, and whilst it's possible to write application logic that ignores such machinery (just as it's possible to do so in various Web frameworks), that machinery is always going to be there.

Or was the point that you don't believe most application code should be working at that level?

A lot of the features you're looking for in a framework are available in other frameworks. For example WebWork 2.2 (soon to be part of Struts 2.0).

So why do you want a Python-based framework? I know it will reduce the learning curve, but will it do so by that much? In the end you still to have some to generate output (and WebWork have a nice components based approach), and deal with shared issues - and WebWork interceptors do a good job at this.

If you maintain a firewall between the Presentation and the Domain layers, and that's a problem that's non-trivial, then you're free to choose whatever framework you want.

Guido, you've expressed that you want a web library that can function in a web-server-neutral manner. I think you should reconsider the web-server-neutral part.

It almost sounds as though you want to write an application server in python. But why reinvent the http wheel? Let an industry-standard web server do that part of the job, and run Python inside it. You can do everything with very low latency.

mod_python (http://modpython.org) loads the Python interpreter inside Apache. It gives you a library of functions for handling requests, sessions, cookies, authentication -- all the elements of a web application. It doesn't force you into a non-pythonic way of doing things at all -- but it does add a set of modules that can only be called inside the server. And it takes care of all the nitty-details of being a web server, leaving you free to write your business logic, data model, and presentation however you like.

mod_python also doesn't enforce any particular set of tools for templating or data persistence -- it includes a templating language, but it can be used just as well with any other. Because you have a Python running inside the web server, you can import and use anything that is installed in Python.

The documentation is also very good: clear and precise without being either dumbed-down or obfuscated.

mod_python gives me the tools I need to write web applications and then it gets out of my way.