Slashdot Mirror

I've been able to build some surprisingly sophisticated and full-featured web applications using Python wrapped inside CherryPy and sending the output through Django. Really amazing how much you can do with this, with the added benefit of portability if you ever want or need to move it across platforms.

If portability isn't an issue, by using Python's ctypes you can call almost any back-end Linux, Windows or Mac OS X library for the ability to do almost anything you want.

I'm long time Java developer myself and I find Python to be a natural transition. We've been using CherryPy at work and it's a pleasure to use. Clean, concise and simple. And it has a number of templating languages to use as well.

@WilliamBaughman GWT is nice, but it's different than most web frameworks. It's Java code compiled into Javascript. The times I've used it I've come away thinking it has some great features, but it's a little heavy for my taste. Haven't used it in about 3 years though.

I'm long time Java developer myself and I find Python to be a natural transition. We've been using CherryPy at work and it's a pleasure to use. Clean, concise and simple. And it has a number of templating languages to use as well.

@WilliamBaughman GWT is nice, but it's different than most web frameworks. It's Java code compiled into Javascript. The times I've used it I've come away thinking it has some great features, but it's a little heavy for my taste. Haven't used it in about 3 years though.

I have written a few apps using Tornado... So far it is my favorite framework for developing rich web applications. I contributed code/patches that the Tornado devs used to add SSL support to the framework. Also, just the other day I completed a Kerberos/AD/SSO authentication module for Tornado (I'll be making it available soon I hope).

My favorite feature of Tornado is the built-in support for WebSockets. It should also be mentioned that it is one of (if not THE) fastest Python web frameworks.

I also want to mention that for one-off/quick development web applications that don't need to be super fast I almost always use CherryPy. It is much simpler/quicker to develop with CherryPy than Tornado. You lose out big time on speed but the development time of CherryPy apps is very impressive. I wrote a reporting tool for my job that would examine a passwd file and then check it against Active Directory for uid/gid/shell/homedir conflicts and report the results on a pretty page using jqGrid. Users could even click a button to export the grid to spreadsheet format. Total development time: 16 hours (and that includes lunch breaks and five or six hour long conference calls)! Needless to say my boss was ecstatic, my coworkers were amazed, and the people who ended up using the tool asked me how much it cost (as if we bought it).

To bridge the gap between CherryPy and Tornado I actually wrote a MethodDispatcher that lets you port a CherryPy app to Tornado with a trivial amount of effort. Of course, it also lets you write a Tornado app "the CherryPy way" which, while a bit strange sitting on top of Tornado, is much simpler and allows for faster development time.

As for the differences between some popular frameworks I wrote up a pretty good explanation over at Stackoverflow.

For reference, here's some apps I've developed using Tornado: Gate One (still developing it), PyCI (no longer maintaining it though--I hope to revisit it some day when I have time, sigh), Escape From The Web, and here's a writeup of mine on how to develop an application similar to my reporting tool using CherryPy and jqGrid in no time at all.

libopenssl isn't a general requirement of OpenWRT because all the default web-based interfaces (LuCI, X-WRT, etc) don't use SSL (not by default anyway). I suspect the reason for this is precisely because libopenssl is so large (from an embedded perspective).

PyCI requires the pyOpenSSL package because PyCI was built using the CherryPy framework which currently uses that module for SSL capability. The next release (3.2) will support the regular Python SSL implementation and I plan to get rid of the pyOpenSSL requirement when that happens.

1-4 Address valid points, but each project is different and sometimes the overbearing factor is performance.

When developing web applications one of the largest bottlenecks can be rendering of templates. I always use clearsilver for templating, it's written in C and orders of magnitude faster than any other template engine I've come across.

The issue then becomes, which framework uses clearsilver? I didn't find a satisfactory solution using similar criteria as 1-4, so I hacked clearsilver support into cherrypy. I'm sure there's many other solutions out there.

The basic point is that every project is different, so different criteria should apply to selecting the appropriate framework.

It seems they recommend just a standalone process behind apache for production setup.

Don't forget to check out CherryPy too. It's also used in TurboGears.

---------------

Slow Down Cowboy!

Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 38 minutes since you last successfully posted a comment

That's one of the first things I checked. According to the CherryPy website, the 2.1 version (currently in release candidate stage) will integrate directly with mod_python.

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.

The server was down for some time because of Apache (maybe too big overload?)
Anyway, I just launched the service today... So it's great to test out the application like this.

FYI:
I now run on CherrPy's own server - and this seems to work pretty fine!

If you're like me and downloaded the latest cherrypy to follow along with the article, there's a quick fix that will make version 2.1 work with it. Just change any lines that say:

from cherrypy import cpg

to:

import cherrypy as cpg

More info here.

If you're like me and downloaded the latest cherrypy to follow along with the article, there's a quick fix that will make version 2.1 work with it. Just change any lines that say:

from cherrypy import cpg

to:

import cherrypy as cpg

More info here.

The link to the CherryPy website is http://www.cherrypy.org/
Maybe the post should be updated to include this.

What your post boils down to is you complaining that in order to use something new, you have to learn something new.

Well, duh.

Anyway it's all here: CherryPy behind Apache

def index():
    return 'Some text'
index.exposed=1

def loginUser(Name, Password):
    #... stuff goes here
 
loginUser.exposed=1

dude=Person.get(1) # SELECT * from TABLE where ID=1
 
dude.name='Fred' # UPDATE TABLE SET name='Fred' WHERE ID=1

class Person(SQLObject):
    _fromDatabase=True

<:import foo:>
<table>
    <:for `foo.Users.getSome()` u:>
        <tr><td><:val `u.username`:></td></tr>
    <:/for:>
</table>

Check out http://cherrypy.org/ as a lighter weight python framework. It's not exactly an apples-to-apples comparison, but it's not as slow as Zope/Plone.

If you are comparing Rails and Zope, you probably aren't comparing things properly. Doing a CMS? Then Zope has a lot of infrastructure, and Rails has none. Doing a small databased-backed web application? Then Zope will be rather painful.

If you want to compare a Python option to Rails and Ruby, you should look at something like Paste/Webware, CherryPy, Subway, Aquarium, or others. There's a lot of choices, but there's very active work to bring together these web platforms, so won't be trapped by your initial choice.

15% - 30% faster! Wow. I hope anyone who ever developed anything for java is reading this so that they can start reimplementing all their code right away.

Another showdown I'd like to read about is that between Rails and Cherrypy. Not in terms of technological superiority, but in terms of marketing skill. Why is the web abuzz with Rails, while Cherrypy is almost unknown.

This isn't flamebait. I'd really want to know how they did it.

Similar ideas worth taking a look at for python:

http://www.cherrypy.org/

BSD Licence, also based on MVC style design.

Python has a great low-level framework called CherryPy http://www.cherrypy.org/ and a Rails-killer called Subway http://subway.python-hosting.com/, built on top of CherryPy, Cheetah and SQLObject

For Python, I have been experimenting with CherryPy which is a fairly low level web application framework, but is easy to use for publishing web services using XML-RPC, generating dynamic HTML (it does not have a template language but works with a few Python HTML template packages), etc.

Anyway, CherryPy "seems just about right" - light weight and easy to use - definitely does not have the capability of Rails though.

Heh, hehe, okay.

According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...

In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.

Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.

On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.

Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.

Jakarta Ant -- PyAnt , SCons

Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile

Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.

Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.

Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.

ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.

OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.

ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.

Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.

Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.

As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.

Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.

There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.

Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.

Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.