Slashdot Mirror

Python, Python is my favorite language, however it isn't that good for web.

Go home, comment. You're drunk.

Django, Pylons, Bottle, Flask, TurboGears, Zope, Web2Py...

And that's just some of the popular frameworks..

I read elsewhere that TurboGears was progressively included this time around. For those that don't know, TG is the software powering the new front end for Source Forge, among many other sites. This is worth mentioning because as other comments will indicate, RHEL is notorious for containing nothing new or relevant for modern development and frequently lags many, many years behind modern distributions. The fact RHEL includes a powerful, modern, and highly scalable web framework is certainly good news.

Hopefully this is the beginning of a new trend for RHEL to remain relevant for modern web infrastructure.

So you're not personally familiar with python-based web development. There are a great many people out there that are though: Django, Pythons, Turbogears, Zope are all great places to start.

You are absolutely wrong about Smarty, which is a horribly conceived and implemented disaster. Don't be such a yapping apologist, just because you managed to throw together your home page in PHP without knowing any other languages.

I am speaking from experience, having had to use PHP and Smarty, and having read the source code to Smarty in an vain attempt to figure out how it worked and why it was so difficult to get it to do even the simplest things correctly. I've been much happier using other better designed templating systems, which I will describe below.

You should read Wolf's Rants about PHP: Truth about short open tags and Smarty.

After this point, the discussion about the tags comes from shopt open tags to "then what should I use for templating?!? and people would go "Wooo! Smarty! Go with Smarty!", and would make me slap people senseless just for saying that. Just as hating PHP for number of damn good reasons, I have a number of hating Smarty to go along with it. Brace yourself, because here it goes:

1. Smarty is programming language
2. Smarty is overkill in majority of cases
3. Speed: Smarty isn't a solution. it's the major problem.

and here go the details about stated points above:

1. Most people would argue, that Smarty is a good solution for templating. I really can't see any valid reasons, that that is so. Specially since "Templating" and "Language" should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is "better for designers, since they don't need to learn PHP!". Wait. What? You're not learning one programming language, but you're learning some other? What's the point in that, anyway? Do us all a favour, and just *think* the next time you issue that statement, okay?
2. I think, that "overkill" is an understatement. You're trying to disguise simple outputting in a complex set of classes,which implements a programming language inside of it -- Definitively overkill". "But it does caching". No, not really. "Caching", in the terms of Smarty is nothing else than converting that template code into PHP. See? I told you there is no point in using Smarty. It doesn't make your life easier. It doesn't make developer's life easier, and it doesn't make server's life easier.
3. The previous paragraph says it all about the speed slugs in Smarty, but I feel the urge to recap that:
1. "caching" mechanism sucks. It's not a proper caching. It's just a conversion of one interpreted language to another one. and in very unoptimized way. If you want to do the proper cachin, go with APC, Zend optimiser or EAcellerator.
2. The implementation of one interpreted language in another interpreted language does nothing but slow everything down

I use Drupal for my home page, so I know first hand that it sucks, and why. My dislike for PHP comes from hands on experience, writing and reading PHP code, not just reading web pages about it. PHP is not my only programming language, so I don't lack the perspective to compare it to other alternatives.

Python has a wide range of templating systems, some of which are much better than Smarty, and a few of which are almost as bad (but none are worse).

Zope uses DTML, which is unstructured and messy but gets the job done. It also has TAL and METAL, which are cleaner and more powerful, but an incredible pain in the ass to use, and extremely verbose and clumsy. I've written a lot of DTML, TAL and METAL, and I don't want to ever use them again, because I've found much better Python based templating systems since then.

TurboGears uses Kid, which is a very nicely designed an implemented templating system that provides a thin XML veneer on top of Python, and doesn't try to reinvent its own p

This is exactly why I use Turbogears and not Rails ;)

CakePHP Framework (supports PHP5 & PHP4), Version 1.2 Stable due any time soon.
Symfony. PHP 5 Meta Framework using Propel and other layer components. The accompaning book (free PDF, buyable dead-tree) is a very good documentation.
Prado. Event-Oriented PHP 5 Framework. Very interesting.
Code Igniter. Lightweight PHP Framework for smaller stuff. Neat website.

Django. Python Framework.
TurboGears. Python Meta Framework using some 3rd Party stuff like Templating layers and such.
Zope Web Application Server. To date unmatched. What Rails wants to be when it grows up.

Like Python with TurboGears or Django?

Yes, Ruby is the current web development flavor of the month, however, don't get caught up in the hype. There are good number of MVC web development frameworks in other languages, including even Lisp and Smalltalk, but most notably Python. In my opinion it makes more sense to learn a Python framework for a number of reasons. Mainly because Python is used in considerably more non-web applications than Ruby, which makes your skills more portable (and you more employable). Ruby on Rails is also very monolythic, while two of the the three most popular Python frameworks, TurboGears and Pylons are very modular (especially Pylons since it's built around the WSGI spec). Finally, Python compiles to bytecode whereas Ruby does not. Hence Python outperforms Ruby in almost every shootout.

Further reading:
Of snakes and rubies; Or why I chose Python over Ruby
TurboGears and Pylons (a technical comparison)
From PHP to Python (my blog)

django and turbogears both run fine on apache1 too. or on lighttpd... or basically anywhere where there is fastcgi or scgi:

http://code.djangoproject.com/wiki/ServerArrangeme nts

http://docs.turbogears.org/1.0#deployment

generally speaking, when you want to run a python web-application, you want to avoid to have to reload the whole application by every request.
because of this, CGI is not suitable, but there are many other ways:

- scgi
- fastcgi
- mod_python
- standalone python http servers (afaik turbogears and zope do this)

(of course, it's still true, that it's easier to find php-hosting than python hosting)

OK, mildly funny, but do we have to take sides?

Here is an observation: With all the publicity Ruby on Rails and other frameworks like Zend Framework, Turbogears and the like are receiving these days--why are we not seeing an innumerable number of security trolls like Chris Shiflett on the *framework side of web development? My thoughts are that PHP users are told "you can too" when in many cases, with forums other resources like the ten gazillion books, they *can*, to an extent (but either with really bad help or books assuming the reader is not working on a *real* project).

Conversely, Rails, Turbogears and Symphony are, too, saying "you can too." Yet, where are the security trolls? It seems though that the *actual* users of the *frameworks, the ones using them for real-life projects are those who have struggled with PHP and (perl, python, etc...) CGI programming for so long and decided "fuck it." Things like database abstraction (and therefore quoting, etc), single-entry-point, and template-safety are, in the most part, taken care of for you.

P.S. XSS is not a PHP problem!

While the article mentions Catwalk (toolbox app to set up initial database objects) it does not mention some of the very nice new features in Turbogears 0.9a6 (supposed to be real close to 1.0 now):

• Identity Management
  The turbogears quickstart can now create a set of customizable standard classes to handle standard authentication and authorization. A User Group Permission model coming with easy-to-use identity decorators for exposed methods. ( Identity Management Documentation )
• Widgets / Forms
  A system to create reusable Form Widgets (with optional scripting / styles) and to use them in forms -- including support for error display and data retention.
• Internationalization support
• Optional support for SQLAlchemy instead of SQLObject

• Catwalk (mentioned in the article)
  Database tool meant to ease the creation of initial data. Sure, you can always just use plain SQL to set them up, but managing relations between tables can be slow and bothersome, especially for N-to-M relations (RelatedJoins in SQLObject terms)
• Model Designer
  Toolbox tool helping to design your models. (Showing diagrams etc)
• Web based python console
• Widget Browser
  Allows browsing through all available Widgets with working examples, example code and configuration help
• admi18n localization tool
  Tool to collect internationalized strings and create new language catalogs

I started playing around with Turbogears some time ago and like it very much. The documentation is a bit thin at times, but the source code is easy to read and accessible (using ipython to interactively explore things also helped a lot.) I implemented my blog in python and had only minor problems. And the code size also turned out to be relatively small.. For the metrics fetishists:

Blog with tagging, User handling (subscription, email confirmation etc), Image handling (upload, admin, thumbnails), atom feeds (general + tag based feeds) plus some minor things:

• python code : 1181 lines, 40762 bytes
• kid templates : 610 lines, 21200 bytes

While the article mentions Catwalk (toolbox app to set up initial database objects) it does not mention some of the very nice new features in Turbogears 0.9a6 (supposed to be real close to 1.0 now):

• Identity Management
  The turbogears quickstart can now create a set of customizable standard classes to handle standard authentication and authorization. A User Group Permission model coming with easy-to-use identity decorators for exposed methods. ( Identity Management Documentation )
• Widgets / Forms
  A system to create reusable Form Widgets (with optional scripting / styles) and to use them in forms -- including support for error display and data retention.
• Internationalization support
• Optional support for SQLAlchemy instead of SQLObject

• Catwalk (mentioned in the article)
  Database tool meant to ease the creation of initial data. Sure, you can always just use plain SQL to set them up, but managing relations between tables can be slow and bothersome, especially for N-to-M relations (RelatedJoins in SQLObject terms)
• Model Designer
  Toolbox tool helping to design your models. (Showing diagrams etc)
• Web based python console
• Widget Browser
  Allows browsing through all available Widgets with working examples, example code and configuration help
• admi18n localization tool
  Tool to collect internationalized strings and create new language catalogs

I started playing around with Turbogears some time ago and like it very much. The documentation is a bit thin at times, but the source code is easy to read and accessible (using ipython to interactively explore things also helped a lot.) I implemented my blog in python and had only minor problems. And the code size also turned out to be relatively small.. For the metrics fetishists:

Blog with tagging, User handling (subscription, email confirmation etc), Image handling (upload, admin, thumbnails), atom feeds (general + tag based feeds) plus some minor things:

• python code : 1181 lines, 40762 bytes
• kid templates : 610 lines, 21200 bytes

The main TurboGears stuff is MIT licensed. Various components have their own (open source) licenses. LGPL (SQLObject) is the most restrictive one, but that can be swapped out with SQLAlchemy (MIT), if necessary.

http://www.turbogears.org/about/license.html

http://www.turbogears.org/ http://twistedmatrix.com/trac/

Django and Turbogears are the two main python web frameworks. Of the two I personally prefere Django, but Turbogears seems to have more momentum and developers behind it.

You've gotta be kidding me. Whatever. Listen, if you suck so bad that you can't just jump into a language and write, you should go back to school.

Your ignorance of the limitations of programming languages demonstrates that you're young, and still have a lot to learn. Your ability to devise a coherant argument is also somewhat lacking.

Again, I'm being rather blunt, which, admittedly, may not be the most diplomatic approach.

Consider this tutorial. It demonstrates how, in 20 minutes, you can construct a simple wiki using Turbogears and Python. If there is no disadvantage to using C++ in any programming task, then it should be a relatively simple task to achieve the exact application in C++ in the same time period.

I'll be honest with you: I couldn't write a wiki that fast in C++. It would take me 20 minutes just to get to grips with CGICC and the MySQL C++ API. I'd be lucky if I got it saving a single page, let alone an all-singing, all-dancing, AJAX-enabled wiki.

This example is loaded, in that C++ doesn't, to my knowledge, have a rapid-development MVC framework like Turbogears. However, it's loaded for a point; a programming language is more than the sum of its syntax. The worth of a programming language is also determined by many external factors, such as the libraries and frameworks written for it, the speed of the compiler, what IDEs support it, and so forth.

That's not to say syntax isn't important, but it's easier for me to demonstrate the worth of libraries than it is to go into the more abstract benefits of metaclasses and higher level functions.

If you want to argue your case, come up with a decent argument against the points I've raised. If you can't, then at least consider the possibility that you may be incorrect.

• Turbogears. Turbogears may become the choice for webapps with more complicated database requirements, eg apps that require a relational algebra engine rather than a simple object store, given their ongoing work to integrate the SQLAlchemy DB layer.
• Django also looks good
• web.py for a lightweight framework.

I agree that using Python as the "P" of a "traditonal" LAMP stack isn't straight-forward. There are tons of Python-based web frameworks, and the mere choice procedure can be difficult to tackle. Pure mod_python may be the "proper" way for a traditional LAMP-approach. However, I really suggest using TurboGears http://www.turbogears.org/ or Django http://www.djangoproject.com/. At least the former will get you going quicker than most frameworks (and is at least on par with RoR IMHO). Perhaps these frameworks belong to a "post-LAMP era" though..

TurboGears is similar to Rails, but in Python. I don't believe it was inspired by Rails, but the TG people are using the Rails momentum to guide development (in terms of what's working for Rails and what isn't) as well as borrowing a few marketing ideas. (For example, the 20-Minute Wiki tutorial.)

I'm neither a RoR or TurboGears guru by any stretch, but near as I can tell, these are the main differences between Rails and TurboGears (real gurus are welcome to correct/add to this list):

1. No need to learn a new language (if you already know Python). Relatively few developers knew anything about Ruby before RoR became a hit, while lots of people know Python.

2. TurboGears comes with less magic built-in. Which is actually a boon for most people because a few that I've talked to thought that all of the magic in Rails ended up making non-trivial applications hard to both develop and debug. TurboGears is much more verbose. Sure, you have to write a few more lines of code for many typical tasks, but you also have a much better idea of what's going on in your application and can debug it quickly when it breaks.

3. TurboGears ties together several pre-existing projects into one framework rather than rolling their own. This offers a couple of nice benefits. First, it's less work that the TG developers have to do. They neither had to write nor have to maintain much of the code that TG rests upon. Second, it's possible that one sub-project can be substituted for another later on down the road. (I understand that they're already using this feature and are in the process of migrating SQLObject out and bringing SQLAlchemy in.)

4. Better documentation. Python is already exceedingly well documented and the TG folks are going out of their way to make sure that their framework is documented just as well. By contrast, if you're just starting out with Ruby and Rails, the best documentation available right now is a Ruby book and a Rails book, both by the same publisher. Part of the reason I didn't go too far into Rails was because I couldn't afford to invest in the books at the time. (There is a TurboGears book in the works by Mark Ramm which should be out later this year.)

Of course, one potential downside to TurboGears is that you have to learn how the various sub-projects work in order to use TurboGears. But they're not all that hard and are probably about the same amount of effort to learn as all of Rails.

There are also a couple other really nifty things about TG that I'd like to mention. (I don't know if rails has these or not.)

The templating engine, Kid, allows you to draft up a template and give right to your web designer, with placeholder text and all, and have them hack on it in Dreamweaver or whatever they use. When they're done, just copy it back into TurboGears and it simply works. Kid uses real HTML tags and attributes, so web browsers can view the templates directly and HTML editors can edit them without mucking up the template-specific stuff.

CatWalk, the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.

TurboGears is similar to Rails, but in Python. I don't believe it was inspired by Rails, but the TG people are using the Rails momentum to guide development (in terms of what's working for Rails and what isn't) as well as borrowing a few marketing ideas. (For example, the 20-Minute Wiki tutorial.)

I'm neither a RoR or TurboGears guru by any stretch, but near as I can tell, these are the main differences between Rails and TurboGears (real gurus are welcome to correct/add to this list):

1. No need to learn a new language (if you already know Python). Relatively few developers knew anything about Ruby before RoR became a hit, while lots of people know Python.

2. TurboGears comes with less magic built-in. Which is actually a boon for most people because a few that I've talked to thought that all of the magic in Rails ended up making non-trivial applications hard to both develop and debug. TurboGears is much more verbose. Sure, you have to write a few more lines of code for many typical tasks, but you also have a much better idea of what's going on in your application and can debug it quickly when it breaks.

3. TurboGears ties together several pre-existing projects into one framework rather than rolling their own. This offers a couple of nice benefits. First, it's less work that the TG developers have to do. They neither had to write nor have to maintain much of the code that TG rests upon. Second, it's possible that one sub-project can be substituted for another later on down the road. (I understand that they're already using this feature and are in the process of migrating SQLObject out and bringing SQLAlchemy in.)

4. Better documentation. Python is already exceedingly well documented and the TG folks are going out of their way to make sure that their framework is documented just as well. By contrast, if you're just starting out with Ruby and Rails, the best documentation available right now is a Ruby book and a Rails book, both by the same publisher. Part of the reason I didn't go too far into Rails was because I couldn't afford to invest in the books at the time. (There is a TurboGears book in the works by Mark Ramm which should be out later this year.)

Of course, one potential downside to TurboGears is that you have to learn how the various sub-projects work in order to use TurboGears. But they're not all that hard and are probably about the same amount of effort to learn as all of Rails.

There are also a couple other really nifty things about TG that I'd like to mention. (I don't know if rails has these or not.)

The templating engine, Kid, allows you to draft up a template and give right to your web designer, with placeholder text and all, and have them hack on it in Dreamweaver or whatever they use. When they're done, just copy it back into TurboGears and it simply works. Kid uses real HTML tags and attributes, so web browsers can view the templates directly and HTML editors can edit them without mucking up the template-specific stuff.

CatWalk, the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.

TurboGears is similar to Rails, but in Python. I don't believe it was inspired by Rails, but the TG people are using the Rails momentum to guide development (in terms of what's working for Rails and what isn't) as well as borrowing a few marketing ideas. (For example, the 20-Minute Wiki tutorial.)

I'm neither a RoR or TurboGears guru by any stretch, but near as I can tell, these are the main differences between Rails and TurboGears (real gurus are welcome to correct/add to this list):

1. No need to learn a new language (if you already know Python). Relatively few developers knew anything about Ruby before RoR became a hit, while lots of people know Python.

2. TurboGears comes with less magic built-in. Which is actually a boon for most people because a few that I've talked to thought that all of the magic in Rails ended up making non-trivial applications hard to both develop and debug. TurboGears is much more verbose. Sure, you have to write a few more lines of code for many typical tasks, but you also have a much better idea of what's going on in your application and can debug it quickly when it breaks.

3. TurboGears ties together several pre-existing projects into one framework rather than rolling their own. This offers a couple of nice benefits. First, it's less work that the TG developers have to do. They neither had to write nor have to maintain much of the code that TG rests upon. Second, it's possible that one sub-project can be substituted for another later on down the road. (I understand that they're already using this feature and are in the process of migrating SQLObject out and bringing SQLAlchemy in.)

4. Better documentation. Python is already exceedingly well documented and the TG folks are going out of their way to make sure that their framework is documented just as well. By contrast, if you're just starting out with Ruby and Rails, the best documentation available right now is a Ruby book and a Rails book, both by the same publisher. Part of the reason I didn't go too far into Rails was because I couldn't afford to invest in the books at the time. (There is a TurboGears book in the works by Mark Ramm which should be out later this year.)

Of course, one potential downside to TurboGears is that you have to learn how the various sub-projects work in order to use TurboGears. But they're not all that hard and are probably about the same amount of effort to learn as all of Rails.

There are also a couple other really nifty things about TG that I'd like to mention. (I don't know if rails has these or not.)

The templating engine, Kid, allows you to draft up a template and give right to your web designer, with placeholder text and all, and have them hack on it in Dreamweaver or whatever they use. When they're done, just copy it back into TurboGears and it simply works. Kid uses real HTML tags and attributes, so web browsers can view the templates directly and HTML editors can edit them without mucking up the template-specific stuff.

CatWalk, the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.

I think most of the attention ROR is getting is just hype and secondary hype. The first wave of hype drew a lot of PHP developers (90% without any real clue about programming) to evaluate ROR. And of course, compared to PHP ROR is like a gift from heaven.

After the hype around it persisted I tried it out myself. My impression was that it is nice but nothing worth that much hype -- plus I don't really like Ruby that much, its syntax seems to make too many things different just for the sake of it.

The good thing about ROR is that it belongs to a new current breed of web development framework putting emphasis on rapid, easy development. I like the pythonic Turbogears very much (especially the upcoming 0.9 release).

Perhaps Web 2.0 is tired?

No, PHP is tired. It's now all about Ruby, Python, LISP, and the more obscure but no less interesting Lua, Scala, Qi, OCaml, among others, and various derivatives and frameworks.

You know a thing is superhyped when v1.1 is mentioned on slashdot.
Mind you RoR is cool compared to j2EE. Then again, it's allmost as if C is cool when compared to J2EE. J2EE sucks big time for server side web - even the Java Gurus agree on that. End of discussion, no news here.
But RoR isn't the end all of ssi frameworks. Django is at least as good (I'd say better and cleaner than RoR) and Zope has been around since the ninties and still is years ahead of the rest. People with an overview over the technologies generally agree on that. I had a story submission (rejected) on that the other week. Check out the linked webcast, it's a very interessting analysis of a set of technologies and solutions:

|||||
Nasa/JPL Web Framework Shootout

In an educative and entertaining webcast, Sean Kelly, a Nasa/JPL software engineer, goes into the details of a project based comparsion between a set of web application frameworks and servers. Including the much hyped Ruby on Rails and Django. Various Java technologies, Ruby on Rails, Django, TurboGears and Zope are covered. Details and traits of each are mentioned. For people involved with web developement there are not to many suprises though, yet the presentation and Kellys commenting are fun to watch.
In a nutshell: EJB, Hibernate and various other Java flavours fail spectacularly, Zope scores a clear victory with Django, RoR and TurboGears relatively close behind. Development speed, error-gotchas, the need for hand-tweaking and the requirement of handwritten SQL and available documentation go into the measuring. As does an overall tongue-in-check "fun-factor". The details are interessting though. TurboGears 'error-driven' developement gets a positive review, RoRs automated controller generation aswell and Zope gets a complete rundown on it's astounding set of features. In the end long-time Java developer Kelly convinces us that - no matter what we do - we really, positively, don't want to use EJB or Hibernate for this kind of stuff. Very entertaining and informative indeed.
|||||

You could even order the books by ascending ISBN; that way, you have a globally unique ID for every book, without having to mark the books with another number. Also, this would remove the need for an extra primary key column. The only hitch is that now you need to store the number of copies of each book in each record (if you want to store that sort of thing).

If you know Python, TurboGears is a natural candidate for implementing something like this- it provides a nice framework, templating, and transparent DB access without writing a single line of SQL (through SQLObject). You can develop with a sqlite database (flat file or in-memory), then switch to MySQL, PostgreSQL, or a number of others later with little/no modification of code (the only thing I've been bitten by is naming things after MySQL reserved words while developing on sqlite).

I've set up a system kind of like this with code snippets; it uses tags to organize the snippets, then allows you to specify any combination of tags to require. So all Python snippets are tagged "python", everything that deals with SSL is tagged "ssl", and all my C code is tagged "c". If I want code that involves working with C and Python together, I search for "c python". If I want Python SSL code, I search for "python ssl". Couple that with versioning (and a colored diff output when you change something!) as well as a description field, and it's a pretty usable repository. It's nowhere near clean enough to release, but maybe it will see the light of day some time.

Role
I work 60-70% of my time as a member of the core consulting team here and the rest of the time on "IT" administration and management around the local office. I should note though that I am a software engineer first and fore most, but it so happens that in small businesses one must wear many hats. Last year I was also heavily involved in accounting activities and managed a marketing program.

Scale
I only have 30 workstations and 27 servers (only 2 are publicly accessible and 8 are in a RCF) to worry about presently:

Culture
It should be noted that my users are technically very competent, which is a totally different can of worms to you (I assume from your comments), but there are plenty of issues to guard against with too competent a user as well!:) The issues are just different.

Environment
Server OS: RHEL 3
Workstation OS: Fedora Core 4 and 2 MacOS X (those damn graphic designers/marketing folk!:)
VPN Server OS: NetBSD 3 (runs on an Alpha box)

Software Tools
SCM: Subversion http://subversion.tigris.org/
Issue Tracking: Trac, which integrates nicely with Subversion http://edgewall.com/trac/
Internal Documentation (for future growth): Trac's built-in wiki http://edgewall.com/trac/
Web Server: Apache, mod_python, mod_ssl, mod_dav, and all that good stuff http://apache.org/
Knowledge Base: OpenCyc (but looking for something better that is still open source)
Intranet Framework: Python 2.4/TurboGears/Apache/mod_python http://python.org/ and http://turbogears.org/
Authentication: Fedora Directory Server (LDAP)
Updates: Yum, up2date
Server Monitoring: Nagios http://www.nagios.org/
[Internal] Remote Access: ssh and Gnome/VNC for the rare visual task
[External] Remote Access (i.e. VPN): OpenVPN

Internal Tools
Fixed Asset Management: Rolled my own TurboGears Web/AJAX application that hooks into our accounting system (it took 3 days part-time).
Backups: Rolled own Python backup mechanisms including scripts
Deployment Tools: Using Python's autoinst http://autoinst.tigris.org/
Continous Integration: I have started using Bitten instead of using cron and shell scripts to launch Python distribution builds and tests on a nightly and "continuous" basis for immediate feedback - something I find invaluable.

Office Software
As mentioned in a previous posting using a good calendaring tool is a very good idea. My recommendation is the Calendar extension for the Mozilla suite of tools.

Some of you might be interested in a recent Presentation / Screencast given by Kevin Dangoor (creator of the TurboGears Python web framework) given at this year's Pycon. Although he does talk a bit about TurboGears, most of the talk is tips and examples on how to add functionality using Ajax without confusing users.

Some of you might be interested in a recent Presentation / Screencast given by Kevin Dangoor (creator of the TurboGears Python web framework) given at this year's Pycon. Although he does talk a bit about TurboGears, most of the talk is tips and examples on how to add functionality using Ajax without confusing users.

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

Also, you forgot Django in your mentions of Python web frameworks.

Well, I did not really forget it, I ignored it. Mainly to avoid the "there are lots of frameworks, all of which suck" discussion. From what I see Turbogears currently gets the most attention and is the closest in terms of "packaging" (including screencasts, PR etc.) to RoR, so I picked it for comparison.

Chriss

--
memomo.net - brush up your German, French, Spanish or Italian - online and free

Since this is inevitable to pop up, a very simplyfied version (slightly offtopic):

Why not ditch Python and use Ruby (on Rails)?

• Ruby is a nice language. It looks more like Java (or C or Perl) than Python, so that may be an advantage for those who dislike Pythons whitespace handling (I think it is genius)
• Rails is a very nice framework for developing database driven web-apps very fast
• Someone (David Heinemeier Hansson) really cared to make this user/developer friendly. There is good marketing, nice screencasts (although basically smoke and mirrors), good documentation, a well structured central web site, lots of support. All this may be even more important than the technical differences to other platforms like Python.
• It's hype, so you could easily sell it to management

Why better stick with Python?

• Most of the hyped features Rails are available on Python too, although not yet in such a nice package. The Turbogears folks try this, but in a more pythoniac way. I like it better, since they actually bundled already established products like CherryPy and SQLObject instead of simply writing from scratch. This may not result in a smooth package like RoR, but it is more clearly aimed at the integration of other products.
• There are tons of modules and documentation for Python out there. So if you come to the point where you want to include other features than those already present in your framework, it will be easier to add them from different sources, because a) there are more and b) integration is a more established process.
• There has been a lot going on in the RoR aftershock to improve the situation, like discussions about merging the different frameworks (Turbogears/Subway) to create a unified and very powerful platform.
• There is always a way up in Python with Zope (although this is a beast and documentation is bad, 3.X is much better, but lots of products currently still require 2.X) and integration in J2EE.
• Python is old. There has not only been one generation of developers whos projects failed, but many. RoR is still in the "early adaptors" phase, where everyone sees the revolution and casualties are accepted. Ruby alone has had a strong following in Japan, but for the rest of the world Rails was the first contact. Wait a year until the "RoR sucks" postings appear, than you'll be much wiser.

Chriss

--
memomo.net - brush up your German, French, Spanish or Italian - online and free

Please. For years the Java wonks have been calling performance a strawman argument, usually followed with "get a faster machine".

Now they're using exactly the same performance argument to argue against what is now one of the premier up-and-coming programming environments? Now the table turns; if ROR or my fave the Python-based TurboGears is too slow -- well then, get a faster machine. That argument worked with Java; now it works with Java's replacements.

• Django: http://www.djangoproject.com/
• Turbogears: http://www.turbogears.org/
• Subway: http://subway.python-hosting.com/

In the meantime, if you want rails-like development but with Python check out TurboGears.

It's been raising quite a storm lately, and for a good reason!

I know the other frameworks are in Python, but I don't have a problem with tabs. Can anyone make a comparison about why Ruby on Rails is better or worse than these other two rapid web prototyping frameworks? I haven't coded in Python in 4+ years, has Ruby become significantly better or different than Python for web, text, and database processing?

http://turbogears.org/download/
http://www.djangoproject.com/

Thanks to anyone who has used all 3 frameworks or has any insight.

Jim

I think the proper Python alternative to RoR is something like Turbo Gears.

Python doesn't have anything like this yet.

Hey; I get to be the first to tell you! Yay me. :)

EasyInstall. And no, this isn't some "fringe" thing: TurboGears uses it as it's basic installation method.

I'm not sure on inclusion in the standard distro (of EGGs and EasyInstall,) but I know people are talking about it.

I'm using Rails for a project I've been working on for a month. It's better than anything I've used, but I can still see some room for improvement.

I've seen mention of a few alternatives that look quite interesting. In particular, TurboGears and Django for the Python crowd, and Nitro as another Ruby platform. Others exist for other languages. (I don't know if anyone has exactly defined what makes a system Rails-like; it seems to be one of those things that you can identify without being able to easily describe.)

I'd prefer to use Python, just on language preference, and a potentially larger selection of libraries to use on the back end. But I'm wondering if Ruby has some features that Python doesn't that allow a lot of the magic to happen behind the scenes without having to add code.

I'm also very interested in anyone's experience with Nitro+Og. Og looks like a lot better ORM framework than ActiveRecord.

I'm tempted to try using TurboGears or Nitro, because they look better from a technical perspective. But Rails has so much momentum that I'm not sure they'd be able to surpass Rails' community support, which is in many ways more important.

I love TurboGears. It is easier to set up and SQLObject is nicer to work with than the database tools in Rails. but it is also a Python based framework, so if you are a rubynista, then rails is defiantly the way to go.

It's also in written form on the site.

http://www.turbogears.org/docs/wiki20/index.html

Brian