I would also recommend Pylons - I've used a lot of Python web frameworks over the last few years (Zope, Quixote, Subway, CherryPy, Webware, Aquarium, TurboGears and more), but Pylons has been by far the easiest to work with, letting me do things how I want w/o getting in the way and when I mess up it is easy to work out why (even fun with Ian Bickings ajax'y web debugger!). The combination of Pylons and SQLAlchemy is very flexible and powerful w/o undue complexity - Mike Bayer's earlier comments on his design approach for Myghty (used in Pylons) and SQLAlchemy 'getting the job done w/o any letdowns' ring very true, as do Ben Bangert's on Pylons.

If all you need is your last five bullet points, and you plan on writing your own auth framework, Aquarium is perfect for your needs. Those are the things that it concentrates on and does best. It probably comes down to whether you like Cheetah or not.

PJE wrote:> Looking back at your post, I just realized you hadn't> actually read the WSGI PEP, so I should probably mention> that it it's basically a port of the Java servlet API,> implemented in terms of simple callables and built-in data> types rather than having an object/method interface.

That's pretty misleading: the Java Servlet API provides convenient access to request parameters, cookies, sessions, authentication information, and it supports Unicode properly. As far as Python Web standardisation is concerned, all of those things are on the other side of the canyon and we're still staring at a "Bridge Out" sign.

One of the reasons Django has to do so much toying around with its ORM is because querying is very difficult in Python.

We wracked our heads coming up with an elegant solution to querying. Django does this by messing with keywords, like: records.get_object(<field>__<operator>=<value>), for instance: polls.get_object(question__exact="What's the best framework?") "exact" can be a list of different options, "iexact" (case insensitive) "startswith", "gt", "gte", etc.

The obvious solution is to do some operator-magic, but what object do you use to base __add__ and the rest off of? The best way to do it is get_object(field("question") == "What is the best framework?"), but that was generally considered a bitch. It can be simplified to get_object(field.question == "What is the best framework?"); also pretty bitchy, and is similar to how SQLObject does it: Poll.select(Poll.q.question == "What is the best framework?")

Anyhow, it doesn't seem like that big of a deal, nit-picky. But considering how much of a web-application is querying a database, you have to deal with it constantly. There just doesn't seem to be a pythonic solution to the problem.

> PJE wrote:> > Looking back at your post, I just realized you hadn't> > actually read the WSGI PEP, so I should probably> mention> > that it it's basically a port of the Java servlet API,> > implemented in terms of simple callables and built-in> data> > types rather than having an object/method interface.> > That's pretty misleading: the Java Servlet API provides> convenient access to request parameters, cookies,> sessions, authentication information, and it supports> Unicode properly. As far as Python Web standardisation is> concerned, all of those things are on the other side of> the canyon and we're still staring at a "Bridge Out" sign.

Actually, I'd say it's your statement that's misleading. WSGI provides access to all of those things, and it's up to your application to "support unicode properly". Claiming that it's not standardized is true but not useful. WSGI enables you to use an API of your choosing to access those things, rather than forcing you to use a single "standard" API.

In a sense, you can compare WSGI to XML; it's just a serialization, which means there can be numerous API implementations that manipulate it: DOMs, SAX, pull-DOMs, ElementTree, etc. This means that over time, whatever APIs the community considers "best" will dominate. WSGI is there to support the evolution of *de facto* API standards, not to create a "de jure" API standard.

So, if you want something like the WebStack (sp?) API to triumph, make it available for WSGI and promote it to other people doing WSGI stuff. If it's better than its competition, people will use it.

What does it mean? Nothing probably. But I also notice that new stuff comes first (the first set has not reached version one yet!). So if it means something is that everybody is still looking for the Grail!

I'm arriving a bit late to this topic (that's what I get for being on vacation!)

As this thread has shown, there's a lot of great activity in Python web development right now. I'm very happy to be a part of what's going on with TurboGears.

The goal with TurboGears is to help out with as many of the common web development needs as possible. I like to see things done in a way that is like working with straight Python (I'd say "Pythonic", but you're the final arbiter of that one!).

By combining several great projects, we've got quite a bit of cool stuff happening throughout the project (plus all of the infrastructure build-up of a book coming from Prentice Hall, classes ongoing and in development, improvements in hosting).

I think TurboGears has a fun and easy API but, of course, I'm biased. With all that's happening, I'd say take a look around at the APIs people are offering and go with the one that looks the most fun to use and comes from a vibrant project. There are several packages that will meet your needs, so you'll definitely quickly get into the subjective areas of which one feels best to you.

> In a sense, you can compare WSGI to XML; it's just a> serialization, which means there can be numerous API> implementations that manipulate it: DOMs, SAX, pull-DOMs,> ElementTree, etc. This means that over time, whatever> APIs the community considers "best" will dominate. WSGI> is there to support the evolution of *de facto* API> standards, not to create a "de jure" API standard.

I don't think de facto API standards will emerge magically via evolution. At some point a real standard (a useful standard of any kind) requires someone to step back and figure out what needs to be done to make it so. I think people assume somehow evolution will do that hard work all on its own. But developers aren't fruit flies, and live-or-die natural selection operates far too slow to be effective. People have been hoping this will just happen in Python web frameworks for years. But the withered older frameworks aren't dead yet, and the number of viable frameworks hasn't decreased.

For instance, an emerging standard is one developed in TurboGears and Buffet for calling templates. Imagine instead of the collaboration and combination of APIs that happened, that instead one of these frameworks (let's say TG) had just done what they needed to do to make template plugins for their framework and needs. They would have done something similar to what happened -- there'd be docs on how to write a plugin, and users who use and contribute plugins, and all the trappings of something ready to emerge as a standard. But then someone would come along and think "hey, I'll use their standard." And it would have kind of worked. They might have to mock out some parts of TG during the extraction process, and maintain those mock interfaces as TG developed. They'd have some problems, and they'd submit bug requests to the TG developers about the expectations in the interface and whatnot. And the TG developers would think, well sure that's nice, but that doesn't really matter to us, it works fine for us, and we have our own things we need to deal with. Everyone would eventually go their own ways, frustrated with the process.

This is why standards don't just emerge. Instead someone has to commit to making something appropriate for a standard -- well enough defined, applicable to a wide enough range of problems, distributed in a reasonable way. They can extract the standard from working code, but that is a conscious and willful act, and only the beginning of a standardization process.

I believe WSGI is a good basis for further standards. But Paul is right -- WSGI is not a complete web programming API. There is room for more standards, though I personally don't believe that those standards are best made on a framework API level (e.g., standards for a request object). There's lots of more interesting or useful standards that are within reach -- like that templating plugin standard. But they won't emerge without a push. (And even with a push it isn't inevitable -- I think, for instance, that WebStack is just trying to standardize the wrong thing at the wrong time)

Because standardization is hard, it works better when you don't take on too much at once. WSGI lets us approach some new areas piecemeal, without trying to birth a fully-formed standard. Sun can do what it wants because it owns its world. It's harder for us. But that's not all bad either.

In the sense that WSGI provides practically none of the methods or classes that the Java Servlet API provides? I think most people would agree that in a "port" of an API the methods and classes are everything.

> So, if you want something like the WebStack (sp?) API to> triumph, make it available for WSGI and promote it to> other people doing WSGI stuff. If it's better than its> competition, people will use it.

Well, I don't particularly care if WebStack "triumphs" or not - licensing it as LGPL is as much a statement of that sentiment. And it does support WSGI to a certain level, anyway.

> > I'd be interested if you have different initial> opinions> > about how an 'ideal' templating system would look (I'll> > ignore the framework thing for the moment).> I do also think that valid XML template files are the most> logical path for generating XML/HTML output, and I do> think that big chunks of logic in the template is the tool> of the devil.> > I do agree that the templating language should be as close> as possible to the language being coded in> > But I disagree with your consideration that "code and XML> on the same line is evil", I think that the minor logic of> the templating system should be built in the language,> this is why I usually use Kid: the logic is added with> very simple python expressions (one liners) into the> HTML/XML tags via specific attributes. This means that you> can for example use a generic Python iterator syntax for> building structures from sequence, and use Python's> helpers (such as the itertools stuff) yet you keep a very> clean structure.

The guideline I use, when it comes to what logic/code belongs in a template, and what doesn't, is:

1) If there's a reasonably straight-forward way of doing it in the "template language", I tend to use that (it also keeps the template "language neutral").

2) When it comes to what code to include, and what to leave out, I ask:

- "Is this code concerned with presentation only?"

- "Will this allow me to test the template, using different input?"

If the answer to these is "yes", and the code doesn't obscure the template, then I don't see a problem with it. In fact, if a little logic can be used in the template, preferably using the template system itself (say iterating over an array), then that may be considered encapsulating the presentation logic.

After all, one primary reason for templates is to separate business logic from presentation logic, not code from HTML.

TurboGears is my favorite. I can understand the aversion to XML templating languages, but I really like Kid. It's really much better than anything else I've seen. Check out the Kid examples here: http://lesscode.org/projects/kid/wiki/KidRecipes

My favorite part of Kid is that it guarantees well-formedness, but lets you output to HTML4 if you want.

SQLObject is fine for my needs, but direct SQL should work fine, too.

Lastly, it's hard to overstate how fast prototyping with TurboGears is. The commandline tools it comes with are great. I found it much easier than RoR.

And, whatever you choose for the side, use Bob Ippolito's MochiKit framework for the JavaScript. It's the best.

Django rocks. Probably the only framework where people are putting sites into production without even finishing the tutorial. Also one of the few applications where people have enough faith in the developers to run production sites of the latest svn. In six months or so, i has hundreds of sites in production - including big ones like some parts of washingtonpost.com. And the name rocks too ;-)

I am currently developing an web app in Django after having evaluated others including Turbogears (and RoR). I really wanted to use TurboGears but it was still few months away from becoming a production-level app and I just couldn't wait (or my project couldn't wait for it to finish). Django already had several proven commercial websites and that was the biggest influence.