Yes, of course. The Python indentation made the Pythonland inhabitants to go beyond what was a usual way to do templates. Both Kid and ZPT are, as of my experience, excellent.

“”"
SQLObject allows the database to be defined in Python or the database, which is a good feature.
“”"

And this deserves a dedicated article in the TG documentation, as well as in your forthcoming TG book. Also, standard ways of deployment should be well documented: you might even want to distribute TG0.9 with flup…

SQLObject allows the database to be defined in Python *or* the database, which is a good feature.

And there’s one more thing. This will sound trivially, but still: Development of a web application, especially, for an enterprise-level intranet, is the product of team work: a part of the team makes data (most often, sql) back-end, another does dhtml front-end and the rest glue them together. Therefore, the web application framework must make life easier not only for programmers, but also for DBAs and view designers: No web application framework should compel either sql-wizards or dhtml-masters to learn profoundly the very programming (-scripting) language the framework uses. I guess no Oracle DBA is happy if he/she is made to do the job in Python/Ruby… Therefore, the approach of Rails to employ what’s already done in sql should prevail.
Of course, if the talk is about a personal project, it becomes an advantage to do most of the stuff using only the favorite (scripting) language.

I just want to state my excitment over the following paragraph:

“It all boils down to user experience. In the case of a web application framework, the user is a developer of webapps. Anything you can do to make the developer’s life easier will win users: better and easier APIs, convenient tools and better docs are three examples.”

Thank you for showing great insight!

As tazzzzzzz sort of says, Switchtower is actually more akin to ‘ant’ in the java world — “build management” (well no compiling of course) and managing checkouts, file copies, restarting processes, etc.

Rails still needs to be _deployed_ (process[es] started to serve requests) using FastCGI (most often), or more recently, SCGI (yes, from Python-land — from Quixote folks — with a Ruby driver/adapter). Lots of Rails-folk have turned to lighttpd (instead of or behind apache) for its tiny size and speed, and built-in FCGI abilities. It’d be great if python/ruby had something as generally easy as WARs — I guess wsgi is getting pretty close…

Petteri: I’d recommend TurboGears for rapid, fun web development in Python. Admittedly, I’m known to have something of a bias in that area

Rene: I haven’t generally been discussing Zope/Plone not only because it’s a bit different from what I’m up to, but also because it simply hasn’t come up. I get asked a lot more about Django.

It’s certainly not a matter of me being unfamiliar with Zope. I released one of the earliest Products based on ZClasses, and even worked on porting Zope to Jython (pre-Python 2.2, so that had some interesting challenges). I’ve watched Z3’s development along the way, and even broke ZCatalog out from Zope3 for standalone use.

So, I’m certainly aware that Zope is out there and that’s it’s big and has a big following. That may just be more evidence that there’s plenty of room for Python to grow and become a heavy-duty force on the web even without a “single web framework”. “Yah for diversity”, as you said…

Mark: While I’ve heard of it, I haven’t looked closely at Switchtower yet. I’m certainly familiar with jars and wars. Eggs can actually help and potentially work like jars and wars for deployment, to an extent.

From the hosting companies that I’ve worked with, I can say that they’ve been supporting Rails deployment (sans Switchtower) through FastCGI and SCGI, and it’s generally been working for them. TurboGears can be deployed the same way. Switchtower may make things much easier, though, and deployment is definitely an area that is ripe for improvement.

So far plone+zope is by far the most dominant web framework for python in terms of sites deployed, number of users, and features. You can see this by studying their mailing lists, irc chat rooms, and the vast number of third party products for plone at http://plone.org/

I would guess even more popular than ruby on rails. It also has some very high profile sites using it.

I don’t like it in general, but it is very good for certain types of sites and is a constantly improving, mature technology. It can do vast amounts of things that turbogears, django and the other new frameworks can not do.

Plone+zope is quite different from the style that turbogears/django/subway are all going down. So I think it is great that they exist, and that eventually for this style of web framework one or two of these frame works will be dominant.

Yah for diversity.

Yah for turbogears, and subway. Since I use a lot of shared components as these projects I win because those components should get better documented, bug fixed, tested, and optimized.

Similarly how twisted, django and plone+zope share other parts we all use. Like the database drivers, and python itself. Zope and twisted share parts too.

Other web frameworks, like mighty, webware, peak, etc also contribute to the other projects. Through ideas, specifications, and shared code.

All the different python web frameworks also help in another respect. Getting python recognised on webhosts. So we all have a better chance of using python compared to either php, or java.