According to the blog post I linked to above, Guido “hopes that Django and TurboGears will converge”. Sigh. Someone please tell me that Guido hasn’t fallen for the “Python is losing to Ruby because Ruby only has one web framework” argument. I’m pretty sure he hasn’t fallen for that argument, but just generally thinks it would be a good thing. Django and TurboGears converging would be very much akin to Python and Ruby converging (Tim O’Reilly would probably advocate that, since book sales indicate that Python is waning). They address similar problem spaces and even have some similar approaches in spots, but that’s really a superficial view of the whole.

Guido’s attraction to Django started with Django’s template engine. He compared it with Cheetah and said, toward the bottom:

I didn’t find too many other templating solutions. TurboGears uses Kid which XML-based, like Nevow, TAL etc. IMO these are no contenders because they are XML-based. As the Django folks mention, they use templates to generate non-HTML text files as well. And even if they could be used for this, the verbosity of the XML syntax and the inability to do a proper if-then-else in XML make template writing using XML a non-starter.

For generating HTML, I find Kid to be a natural fit. I think it’s more natural than TAL and Nevow because the programmer just puts standard Python expressions in the right places in their templates (rather than some other kind of expression). Being able to write good, clean XHTML and produce fine HTML for the browser is a great feature and a great way to work. In practice, because I don’t go overboard writing code in templates, so if-then-else has not been a real problem. And, Markup shows a fairly clean way to do it anyhow.

And, certainly, generating non-HTML text files with Kid is suboptimal. First of all, I’d say again that this is not actually a big problem in practice. Seriously. It’s just not something that comes up much on the mailing list. Besides, TurboGears makes it trivial to use one of many other template languages (including Django’s) for generating non-HTML formats. In fact, you can even do it in one method:

When you hit that controller method, by default you’ll get that dictionary plugged into the Kid template to produce HTML. If your browser sends an “Accept: text/plain”, TG will have Cheetah use the same code to generate a plain text view. Nice, huh?

TurboGears has a collection of APIs and idioms that I think make it great fun to work with, and I know others agree with me. Django has its own collection of features that others like working with. That’s fine by me, and it’s not likely to change any time soon.

With TurboGears, I definitely do not suffer from Not Invented Here. In Django’s defense, at the time they started they simply didn’t have the options available that I did when I started TurboGears. But, the Python community continues to evolve, innovate and produce incredible products. TG will benefit greatly from these projects, but it’s unclear that Django would follow suit.

Mike Bayer’s SQLAlchemy, simply put, kicks the butt of Django’s ORM (and that of Rails, as well). SQLAlchemy is already a solid second-class citizen in TurboGears, and will be a first-class citizen soon enough. Christopher Lenz saw the good in Kid and thought he could build a better Kid with Markup. Though it’s a young project, it looks great and has impressive results. Julian Krause liked CherryPy’s quick-and-easy URL traversal, but wanted to break it down to a WSGI core so he created RhubarbTart. Meanwhile, Robert Brewer has completely retooled CherryPy’s easy “filters” feature for CherryPy 3.0. And, for those who like their URL traversal in separate files with regexes, there’s always Ben Bangert’s Routes.

All of the things that I mentioned in that paragraph are not vaporware. With the exception of RhubarbTart, these are things that you can use with TurboGears now and that will likely be included directly with a future TG release. TG has had code contributions from quite a few people, but these things are all steps forward that have occurred completely outside of TurboGears but remain a natural fit for TG.

At EuroPython, during the Web Framework Shootout, we (Simon Willison, Phillip von Weitershausen and I) were taking questions from the audience and someone asked if we thought that TurboGears and Django would merge. My response now is the same as it was then: not very likely. Both projects have their own ideas and approaches and trying to force fit them just wouldn’t work.

Today’s TurboGears 0.9a9 release will likely be the last 0.9 alpha before 1.0 beta 1 comes out. Though many TurboGears users have been running the 0.9/1.0 code for some time, I’m looking forward to finally unveiling it more here, on TurboGears.org and in “Rapid Web Applications with TurboGears”. My thanks, as always, goes to the many TurboGears developers that make the project possible.

> Guidoâ€™s attraction to Django started with Djangoâ€™s template engine.

It’s quite likely it’s never strayed beyond that as well. When I talked to Guido a few weeks ago at OSCON, he noted that he used his own webapp of his own creation with Django templates. Guido was not familiar with Django’s HttpResponse or the rest of the framework.

It’d be interesting to hear if since then, he suddenly aquainted himself with the rest of Django.

Firstly, I should say that I’m a die-hard Django fan. But to be honest, I would love Django and TurboGears to converge into a single framework. That would be the best of all possible cases. Some things need to be settled upon first, including finding the best way to do ORM and templating. No one has hit the nail on the head, as far as I’m concerned, and both relate directly to design problems in Python itself (inlining python into another language/format, and Domain Specific Languaging (can I ‘ing’ that?)) both of which are problems Python, frankly, didn’t need or care to address up until now.

But all of this needs to be natural, not forced. And I think your work with TurboGears is simply awesome. So just because Guido likes Django right now, doesn’t mean you should even stumble on your path. Rock on, man, rock on.

While I agree with most of your post, the example you gave above re: the kid or cheetah templates being used illustrates a huge problem with TG: the lack of documentation. I’ve been using TG for quite a while and I’ve never seen that before. I just checked the docs on the main TG site, and the accept_format parameter isn’t listed. I think that all the work everyone is doing on the codebase is great, but you will need to stop and shore up the docs if you want TG to gain wider acceptance. It’ll also reduce the number of redundant questions asked on the Google group too.

Like Titus said, I also think that Django and TG occupy different spaces. I use Django for more information-oriented sites because I can get a lot done with very little coding (my clients like that too). However, if the site I’m building doesn’t require an extensive admin page, or if it is more of a web-app, I use TG.

s: actually the *entire reason* that TurboGears is not already in the 1.0 beta series is documentation. I’m not willing to call it 1.0 beta without docs.

That said, the doc situation is going to shape up very quickly. Obviously, a 500 page TurboGears book will answer many questions (and that book is certainly written against TurboGears 1.0), and part of that book should be available electronically soon. I’ve been hunting for a good way to make sure that our online docs don’t ever get so out of sync with the product again, and I’ve found a way. Soon, that’ll go live, we’ll convert the docs we have and fill in the gaps and everything will hum along smoothly from there.

I’ve been following TurboGears closely for quite some time now. I was updating my project whenever a new alpha was released. I’ve seen where TurboGears was on its beginning and where it is standing now, a bit before the release of TG 1.0.

I believe that the upcoming 1.0 offers an excellent alternative to any other web framework available today. Both due to the new and impressive “inhouse” developments (widgets, identity, toolbox and more) and to the fact that it integrates with other great software packages.

just FYI with regards to the so-called “problem” of inlining python in templates, Myghty has had this problem solved for over two years. The Myghty template language allows pure python, including whitespace indentation, to be inlined in templates on a per-line basis, including usage as control structures (i.e. conditional/iterated HTML). most people who have worked with it like it quite a bit; since Python is already a scripting language, Myghty chose not to reinvent the wheel in that area.

templates get compiled into real python modules as well, which is why Myghty is able to handle a big site like bittorrent.com (dont let the .html extension fool you; its 100% myghty). and through the buffet plugin you can use it with turbogears as well as pylons, and actually pretty much any WSGI oriented framework with its WSGI adapter.

I *LOVE* turbogears. I have developed couple of in house projects with turbogears having really nice time.

Then confusion starts creeping in. Turbogears have multiple options for everything I want to do. I have multiple templating engines(Kid, Markup, Tal …), multiple ORM (SQLObject and SQLAlchemy). I believe Turbogears was started as pick what best is being offered out there.

Options are good. But they also start creating confusion. I would definitely advocate getting to version 1.0 with given set of tools and then start incorporating other options with really good documentation.

I also believe, django and Turbogears target different set of problems. They both definitely can flourish.

You’ve hit on something that needs to be clarified in the docs and the marketing materials for 1.0. The book is actually quite clear on this (and so is the website, in one sense). As of today, TurboGears consists of MochiKit, Kid, CherryPy and SQLObject. But, TG is a living project and the goal is to continue to apply the best tools for the job. SQLAlchemy is definitely in the future of the project, and Markup is looking quite positive. In many ways, though, those projects will be brought in as “2.0” sorts of substitutes for existing pieces. People who need the functionality offered by those packages and aren’t as concerned about API stability don’t need to wait for all of TurboGears to catch up. Once those options have fully matured, they will become the official components used by the project.

The mission of TurboGears hasn’t changed. There’s still one main path to get the job done, and you only veer off of that path if your application needs dictate it.

I love Python as a language – obviously Guido has done a great job as the Python “benevolent dictator”. Presumably his effectiveness is due to a lot of experience with computer languages.

But when I first read his comments regarding XHTML & Kid, my first thought was that he can’t have much experience with web applications. The extra effort required to create XHTML compliant HTML always seems like a pain when you’re first introduced to it. But when you have to deal with HTML coming from diverse sources, and programmatically verify or modify it, suddenly the fact that all tags are obeying the same simple set of rules becomes hugely beneficial. Typing a few extra characters here and there suddenly seems insignificant.

The web is a bunch of simple technologies that interact in potentially complex and often unexpected ways. Evaluating web application frameworks is a tricky business. I personally think that you need a lot of experience with web applications in order to make a wise choice. After reading some of Guido’s blog postings, I’m not so sure that he fits that criteria. Perhaps he should be asking some of his more “web-experienced” Python programming coworkers at Google to do a detailed evaluation of each of the main frameworks.

An analogy is perhaps rally cars and engines. You would get an experienced engine mechanic to evaluate a new engine component, but an experienced rally driver to evaluate a new car component. An engine is just a component of a car, and a language is just a component of a web framework – although a very important and hopefully well integrated component. But experience with a component doesnâ€™t imply experience with the whole.

As a Zope user, this is an issue that I have had to come to terms with myself.

Rails does some things better than Zope.
So do Django and TurboGears.
This is not a problem, it is simply an opportunity to improve. It only becomes a problem if there is a lack of willingness to adapt to better methods as they become available.
TurboGears should learn from Django, and vice-versa. Rails should learn from Zope, and vice-versa. Obviously, that learning will be integrated from the perspective of the host program, so the programs will still end up very different. That is ok, however, because they cater to different markets. Even knowing practically nothing about Rails, I can still build a simple HTML app in it much quicker than I could with Zope 3. However, if I have long term plans for the app, then I will probably use Zope, simply because the structure fits the way I like to think about programming. I think Zope would probably be better off with more code generation tools, and allowing live updates to the code, but there is work being done in these areas, and I’m very happy with the progress Zope 3 is making.

My interpretation of Ruby and Python are much the same, in that Python has always seemed more straightforward to me, but perhaps less convenient.

I’m not sure what you mean, malcontent… Django and TurboGears both strive to offer “the one true way” (though we all have different “true ways”

Thanks to Summer of Code, SQLAlchemy just picked up migrations. We’ve got setuptools instead of rake (and zc.buildout will fill in for other things you do with rake). TG comes with testing tools. We don’t have capistrano. We *do* have the Toolbox and Widgets.

These frameworks are used for building and deploying apps, so we do go after many of the same problems Rails does. We tackle them in different orders, though, depending on the various needs that we (and other contributors) have.

there *is* no one true way. people have been building web applications since 1995, and software in general for many decades, using thousands of different methodologies, and they keep changing. new needs arise, and new ideas and approaches are introduced constantly; older methodologies fall by the wayside. web development, and software development overall, strives best in a dynamic and highly fluid ecology which welcomes diversity. Communities which do not welcome diversity and arrogantly think they have it “all figured out” already, while they grant an appealing and soothing comfort to its members, eventually are doomed to fail.

by adopting a single monolithic “method”, and marginalizing all other approaches that do not fit this “method”, progress simply stagnates. the “appeal to newbies” justifaction for this is hardly worth it.

I am not a web developer, I am a system administator, but from time to time I have a need to develop some small web application for internal use. I have looked at both Django and Turbogears and find that TurboGears approach of combining existing python libraries (CherryPy, SQLObject, Kid) is the RIGHT way to go. It helps to reuse those components in other projects (I did use Kid after tried TurboGears in writing small script producing HTML statistics pages).

I find it very disappointing to hear Python’s leading developer to make choices about web frameworks for Python.

Great thanks to all developers involved in TurbgoGears and it’s components!

Just because Guido is BDFL doesn’t mean he gets to “choose” what web framework is “the” web framework. His ignorance on the subject is quite apparent by his “converge” statement and his limited knowledge of both Django and TG.

Saying that there is an “official” Python web framework is just stupid. The strength of OSS is in choice; that’s why we have a thousand different linux distros, as many window managers, and a dozen popular languages. I worked through the tutorials of both Django and Turbogears (as well as RoR) and could imagine situations where I would use one or the other.

Hello,
I’ve been (re)evaluating THE two frameworks in the last several weeks. I won’t really comment on documentation, because others did it allready. I’d like to give it a different accent:
when I first looked at turbogears approx. 6 moths ago, I did manage to install it, but it was not THAT easy. At a computer at work, easy_install just wouldn’t work (proxie frotress). OK, download, install by hand. But what? OK go to the windows download page. Figure out. OK. Did it. But there’s this optional thingie mentioned nowhere that easy_install (now using the downloaded components ) asks for. I thin it was paste. OK go fetch it. Use SQLObject from subversion repository. Oh you DON’T have a subversion client? … etc. etc.
one more try, on a homw computer. running windows, again.
I did manage to install.
Then catwalk wouldn’t work.
Got it running.
Then the tutorial wouldn’t work the way described.
Oh, it’s the right tutorial, but wrong version of SW (or the other way round?).
But no way to figure out from documentation.
At this point I asked myself what Turbogears is at all. A framework? A collection of links to good components?
It said, somewhere on the page, it will get better as soon as it gets 1.0.
So I decided to take a look later.
6 moths later:
on the Turbogears homepage it says “TurboGears 1.0 is currently available in a preview release.” Follow the link. Gets me to the “TurboGears 0.9 Preview Site!”. I get the feeling I must be very stupid.
Up until now TG is all flower-power to me. Please don’t say it would be easies under linux. I know it. I dont want to switch. Maybe later. Not now.
Then Django.
It installs with no fuss from one package.
It configures painlessly.
It gives me an authentication framework for free.
It betrayes me on the authentication framework: I get the admin password wrong somehow, and no chance to fix this mistake (there is a utility for that, but it doesn’t work the way it’s suposed to). Goodbye, Django. But the documentation looks very serios, way way way better then TurboGears. No I don’t like its ORM, not at all. The templating is OK, but the database stuff… But I would have gone for it, just to be able to do a professional website NOW, if it just worked as it said it would.
So my current conclusion is to drop back to CherryPy, which just does what it says, and cheetah for templating, and maybe plain old SQL, which I just happen to know, or maybe SQLAlchemy, and probably Mochikit, if I ever need Ajax, and … Sounds like Turbogears, – bits and pieces? Yes I know. But it will be MY confusion, if there is any . Not somebody elses. I’ll know where things are. If they are ugly, I’ll know where to change them… It’s a shame. I’d like to take part, and contribute, when I have something worth contributing.
Plese, Kevin, I’d like to use TG. What do you mean: “a part of the TG book will soon be online”? Which part? Will it be enough to avoid having the experience I allready had, once again? I don’t mind some chaos, but it was just too much. Bruce Eckel said it too, “each one of us would have given up without the support of the others in the group”. Will there be a clear list of obligatory components, and a of the “nice to have” ones? Will there be a dependency list? Where do I find out about this slick way to use several templating systems, even in the same function, that you mentioned in the blog? Do I have to read the code, or hang out all day on the mailing list? If I use SQLAlchemy, can I still use catwalk? If I switch the templating/ORM/Ajax library, what breaks? What IS TG after all?
So please, be assured that I respect your effort and energy and effort put into this goddie for python programmers, and to me it is the way great applications should be created in Python: no NIH, take the good bits, put them together, add value. And I would like to jump on the train. So can somebody plese tell me when there is the next stop, and where is the station?
All the best,
Nenad

Nenad: I’ll be the first to admit that we’ve taken too long in this release cycle. As a result, the version that most people are running now is the one that lacks polish: it’s not as easy to install as it should be, it doesn’t have the docs it should, there are a few bugs that shouldn’t be there.

That’s a mistake I don’t want to repeat, which is why I’m getting things in place to ensure that our docs don’t fall so far out of sync.

Also, as I said above: TurboGears 1.0 is Kid/CherryPy/MochiKit/SQLObject. There is “experimental” support for SQLAlchemy, and you can plug in different template engines as you need to. SQLAlchemy doesn’t have the same level of integration that SQLObject does. However, it’s still the best choice for a certain class of problems and we know it’s the future so we offer support for it.

We’re expecting the first 10 chapters to be online at Safari soon. We’re actually only a little more than 2 months from the scheduled release of the book in print.

TurboGears 1.0 beta 1 or beta 2 is where you’ll start seeing the polish that the original release had come back. The features themselves are polished already, but the packaging needs a little more work.

I agree entirely that it makes no sense for TurboGears and Django to merge, any more than it would make sense for GNOME and KDE to merge. Instead, just as freedesktop.org has helped foster many standards to help GNOME and KDE interoperate, WSGI promises to make components of TurboGears, Django, Pylons, and other Python web frameworks more easily interchangable. In the ideal case, I’d love to use the identity framework from TurboGears, Paste for control and deployment, the TurboGears toolbox, Routes for URL routing and URL generation, TurboGears fabulous use of decorators and dict returns for trivial template hookup, Kid or Markup for templates, MochiKit-based AJAX, and some of the miscellaneous extras from Django like RSS generation. WSGI might let me do just that.

I think there is room for both Turbogears and Python. I write a regular column about Python and Ruby news for a german magazine and it is true that there are many announcements of new Python web frameworks.
but I think most of the Python community will focus on either Django or Turbogears. I think they are both great and for some apps Turbogears might be more suitable and for others Django. And for others Rails.

So I think a little competition is not bad. and both already have a huge user community and both Django and Turbogears will get even better in the future. Just look how far Rails has come during the last two years.
All three Frameworks are amazing software.

By the way. Ruby has more frameworks, for example Nitro (http://www.nitroproject.org). It is not yet as mature as Rails but looks interesting. and I think some competition is also good for Rails.
But I believe for the next few years Rails will be the number one framework for Ruby.

I think it might be good for the Python community to focus on both Django and Turbogears. Two great frameworks are good. Maybe ten would be too much

I also think merging them does not make much sens. this is like merging Ruby 2.0 and Perl 6.

I think the anonymous poster above has sadly mistaken WSGI for a common interoperability for web apps in general when really it’s just a tiny interface sitting at the bottom of the stack.

However, the point about interchangable components is solid. Python suffers from having too many frameworks. But it wouldn’t suffer from having too many components, if they’re easy to swap in and out, and it’s clear what the pros and cons of each one is. For example, a non-XML output system would be essential to me with my current project (CSV output of a database). It’s an ideal candidate for templating, just not XML templating. Shame I don’t see an obvious answer to doing that with TurboGears.

Right now it’s not even clear to me what the difference between Django and TurboGears is; people claim they are aimed at different types of problem, but my cursory glance of the respective webpages and reviews on others’ blogs didn’t show any significant differences whatsoever apart from the degree of polish on different parts of the system. Perhaps clearly differentiating between them will make the decision a lot easier for developers, overcoming the pressure to merge the 2 together, and ending the dilemma of which to choose.

I’m afraid my results have been a lot like Propads. I’ve been eager to get serious with TG since the beginning of the year, but whenever I try a small test project or run through a tutorial I get my shins all bloody on the sharp corners (i.e. bugs, or docs that are incomplete or incorrect). I REALLY want to switch our work over to TG and can’t wait for it to usable… but I’m losing faith in the “it’s just around the corner” marketing words. So about every month I revisit TG and Django and Pylons, give up, and keep limping along with Zope and Plone (which are seriously misapplied in our case).

Bottom line – I, for one, am eager to start using TG when it is finished. And I do appreciate all the effort that has gone into it.

Ben Sizer: I’ll grant that it’s not in the official docs (something that is being corrected now), but take a look back at my original posting… It shows how trivial it is to use Cheetah for doing any kind of text templating (and it can even be done on the same method! One method can generate XML with Kid and CSV with Cheetah).

Bob T: Quite a number of people have been successful in navigating the definitely “alpha” waters that 0.9 has been in. I am sorry for the times that I’ve thought that the final release was around the corner and been wrong. Open source can be very unpredictable, because everyone involved (including myself) have their own personal and professional commitments that allow varying amounts of time to go into the open source project.

Here’s what I can say for sure: I’ve got the tools ready to go to get as many people as I can tackling the doc issue. The book, which is certainly the largest documentation project, will be entirely in editing within 2 weeks. As I mentioned in a previous comment, putting the polish on 1.0 is where we’re at now. Stay tuned and give us a try sometime during the 1.0 phase.

Kevin: the key here is that the Pythonic way is typically to have an obvious solution, rather than a succinct one. TurboGears has always felt to me to be the other way around, more like Perl: you can do just about anything with it, often in a single line of code… if there was a hope in hell of you finding which line of code. I’ve never felt that TurboGears was incapable of doing what I need, only that I am incapable of sparing the hours to find out how it is able to do it. I truly hope these docs are ready soon, and equally importantly, that in future the docs keep up with development.

I have been using TG since 0.5 and I love it! Django is very cool, but didn’t grab me and I have not yet been compelled to look at Ruby or Rails.

That said, Propad’s experience with installing TG has also been my own, even with 0.8.9 as well as 0.9x.

With unrestricted access to the net, TG is stupidly easy to install. This is true. Though you still have to know to get psyopg or sqlite or whatever. But offline, or behind a highly restricted proxy (like at my work), installing TG is a pain. I can do it, I’ve learned how, but it is a pain. I have also seen several posts on the mailing list asking about this.

I have the intent to contribute on this subject, but need the time.

I would like to suggest 2 things, though:

1) Put links to *all* dependencies on the download page, this includes Paste, PasteScript, PasteDeploy, Psycog, PySqlite, Formencode, etc. Everything, including docutils so the tutorial is flawless. Even if they are links offsite, that is fine but make it so that if I have to download everything manually, I can get it all in one place. This is a simple enough addition and I think it would go a long way for those of us stuck in highly restricted environments. Right now we have the equivalent of DLL/RPM hell.

2) I think (and I may have mentioned this elsewhere before) that a Plone-style installer (at least for Windows) that includes Python and everthing that TG needs would be very useful. Perhaps one without Python too. I know that there are a lot of people that use Python on Windows and making things easy for that demographic would go a long way to foster adoption.

I know suggestion 2 would need a champion, but number 1 would be fairly easy to do.

I feel bad not being able to commit to contributing… I want to… but I also believe that the manual install issue really does need to be addressed.

Anyway, I will end this long winded post and just reiterate that TG is absolutely wonderful! And once the docs are in place, things will be even better.

Keep up the awesome work and my sincerest thanks to you, Kevin, and everyone to has contributed to TG and it’s component projects!!!

In an email discussion with Guido, I proposed that the reason he doesn’t like Kid templates is because he’s never attempted to do AJAX programming. Here’s an excerpt from my argument:
——
There are two ways to think about an HTML document – as a stream of text, or as a tree. If what you are doing is primarily textual in nature, it pays to think of things in terms of pasting sequences of text together, inserting snippets of text (‘interpolation’) into larger snippets.

However, one you start doing any kind of serious DOM-level manipulation (such as AJAX), you find that most of your effort is spent getting the DOM tree just right – making sure that all of the nodes are in the right place, that the children have the proper parents, and so on. Your mental conception of the document gradually changes until you are thinking of it more as a data structure than as a text document.

This is where rigorous structured templating comes in – its much better if errors in your document structure can be detected on the server side than having to rely on the haphazard error checking of Firefox, Safari or IE. Trying to rely on the browser’s error console (which half the time reports no error at all, the other half floods you with errors that are meaningless) to detect subtle structural errors is nighmarish to say the least. Better (and faster) to have a server-side template language that won’t *allow* you to make those kinds of mistakes.
——
Guido’s response was essentially “it may well be”…

I don’t think merging frameworks isn’t that important. I actually think Python’s diversity in terms of web frameworks will eventually be a benefit for the language and the community. One thing the EuroPython frameworks shootout has shown is that different frameworks serve different purposes. The important thing is that we should try not to reinvent the wheel too many times. I guess that boils down to creating a foundation that allows us to work together. Given efforts like WSGI, I’m optimistic. Let’s create more of such efforts!

For instance, I would like to include a django created application in my zope server. And use kid templates in zope. Or include a zope based CMS inside turbogears. The key here is that there should be one and only one obvious way to do it.

On that account WSGI is a big step forward, but only for the interface of the webserver to the application server. The WSGI interface is too low level for application developers. What we need is a common interface at the application level. All frameworks provide a request object with form data end HTTP request info, a response object, a user object for security checks, a session object and an interface call a template. The functionality is exactly the same, but how to use it is very different for all the frameworks. For a language where “one way to do it” is a mantra, the situation is damn awkward.

In Java, the situation is much better. There people have the servlet API. Although there are many different implementations of that API (WebSphere, Tomcat, WebLogic), applications can be ported painlessly from one environment to the other. (Painless is relatively speaking of course, it still is Java, we are speaking of.)

If all frameworks use common interfaces for request, response, user, session objects and template interfaces we take a giant leap forward. There would hardly be a penalty in learning costs to switch between frameworks. It would allow a django app to forward a request to a zodb object and have the results formatted by a cheetah template.

But best of all, it would allow the development of framework independent libraries. For instance, zope contains a very powerful marshalling library. This allows fields in a complicated form to be mapped to integers, lists, records or combinations of the above. If there were a common request object, I could then rewrite this as a library that simply manipulates the data in the request object. It would instantly be useful in any of the other application frameworks.

So, it is not that there can be only one, but there should be only one way to do it.

The biggest problem with Turbogears is that it requires the easyinstall stuff to use it. I have run into so many problems with eggs and easyinstall that I refuse to use it anymore. If I can’t find a straightforward tarball for a Python app, then I won’t use it.

Python is for developpers not endusers. A developper does not want an all-in-one install package that only allows you to install a package in the one true fashion. That’s why I like tarballs, because I can install it where and how I want without disturbing any other parts of my system that I don’t want to disturb.

I use some of the components of Turbogears but I will never use Turbogears itself if it remains exclusively egg-based.

“the key here is that the Pythonic way is typically to have an obvious solution, rather than a succinct one. TurboGears has always felt to me to be the other way around, more like Perl: you can do just about anything with it, often in a single line of codeâ€¦ if there was a hope in hell of you finding which line of code.”

This is a documentation issue. It is not a lack of Pythonicness… We do strive to have one “obvious” way to do something. But, it’s not obvious until you get the basic feel of the framework. The same is true of Python: once you get a feel for it, things become obvious. But, that doesn’t obviate the need for the library reference. You still have to know what methods and classes, etc. are called even when using Python with its stdlib.

For an example of what I mean: the “TurboGears way” is to make controller methods just simple, application-focused code as much as possible. The specification for how that method interacts with the web is done declaratively through decorators. Generally, the behavior of the decorators can be overridden by values returned by your controller method, but that’s the less-common case… we’ve optimized for the things people do all the time. Once you get into that, it becomes pretty natural to grab for the decorators…

Which is where the docs come in (or rather don’t come in enough right now).

I agree with folks above about sharing infrastructure and how WSGI helps here.

Michael: I’ve been using eggs for a year and I’ve witnessed how far they’ve progressed in terms of being easy to install. They’re not perfect, but I think they work quite well, especially once you’ve setup a distutils.cfg file to put things in the right place automatically.

Typing “easy_install
” isn’t a win because I would have a hard time installing that package. It’s a win because I don’t need to go to the cheeseshop, find the package, go to its home page (or the annoying sourceforge download pages), get the tarball, untar and finally run setup.py.

For TurboGears, you’d have to go through that drill a dozen times. For packages that do a really good job reusing code from others, this will not be uncommon. Instead, you get one command that picks up everything for you.

Additionally, setuptools provides the automatic plugin discovery mechanism… this makes widgets and template engines and Toolbox tools, etc. all show up without any additional configuration or installation into special locations.

I *will* grant that easy_install isn’t perfect for all cases. Jim Fulton did a good job explaining to me how eggs are a good solution for some of Zope Corp’s needs, but that easy_install isn’t quite what they need. So, they’ve created zc.buildout to use the egg format with some different constraints on how installation happens. It’s a cool and useful tool.

A few years ago when Perl was still quite big and generally had some buzz, people would criticize Python for lacking something like CPAN. The cheeseshop is only half of the solution. The CPAN perl module was key, because you could install a library with all of its dependencies in one go. easy_install does this for us in Python now. (Ruby has Gems, so they’ve gone after that issue too.)

I think setuptools is important. Sure, the implementation is not 100% perfect, and zc.buildout shows that some folks have different needs than what easy_install does. But, that doesn’t mean that it should be tossed.