Domain: cherrypy.org
Stories and comments across the archive that link to cherrypy.org.
Comments · 24
-
Python with CherryPy and Django
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. -
CherryPy
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. -
CherryPy
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. -
Re:missing tornado....
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.
-
Re:PyCI will work with *any* OpenWRT router
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.
-
5. Performance
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. -
Re:mod_python support?
It seems they recommend just a standalone process behind apache for production setup.
-
Re:OpenDoc Cookbook
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 -
Re:mod_python support?
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.
-
Re:Rails everywhere.
To me it seems like a silly exercise to replicate rails in python or what have you.
- TurboGears is not a Rails clone.
- Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
- Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
- 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:
- 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.
- 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.
- 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.
-
Updates
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! -
Quick fix for 2.1
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. -
Quick fix for 2.1
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. -
Link to CherryPy website
The link to the CherryPy website is http://www.cherrypy.org/
Maybe the post should be updated to include this. -
Re:Wow, dude. Chill.
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 -
Clue-stickWhy is CherryPy good? It makes the simple cases REALLY simple, and it can get out of your way if you have more complex cases.
def index():
How simple? Your form submissions get turned into variables passed to the action page, which is a normal function.
return 'Some text'
index.exposed=1
For instance, if your form has fields Name and Password with action="loginUser", you write this:def loginUser(Name, Password):
And the arguments will be automatically passed. With CherryPy, your web app embeds its own multi-threaded web server; one practice is to put it behind Apache, so you can integrate it with already existing setups. It supports the Python Web Server Gateway Interface (WSGI) so you can use mod_python, IIS/ASP, FastCGI, SCGI , etc.
#... stuff goes here
loginUser.exposed=1
The ability to use Python makes web programming bearable again. Want something cool? SQLObject turns your SQL (MySQL, PostGres, others) into Python objects.dude=Person.get(1) # SELECT * from TABLE where ID=1
What's more, you don't have to define your class in code. You can read it straight from the DB schema:
dude.name='Fred' # UPDATE TABLE SET name='Fred' WHERE ID=1class Person(SQLObject):
You can also combine CherryPy with your choice of templating system. And for version control, check out how Trac works with SVN at the CherryPy site.
_fromDatabase=True
If you're sick of PHP, learn Python and enjoy programming again. -
The best web dev framework you've never heard ofWell, for web development (God, do I now have to call this "RIA development"?) I found a diamond in the rough.
It turns out there's this Python-based application server/templating language called SkunkWeb (http://www.skunkweb.org/) which seems to be the Holy Grail for me of, well, a Python-based web framework that doesn't completely suck (Okay, I know 1995 and CGI was awesome and everything, but no one should be writing "print '<html><head>'..." statements within Python code to make web pages, and don't get me started on Zope.) And no, I'm not affiliated with the project or its developers.
I don't know about Ruby/Ruby on Rails, but I'd rather write in Python which, to me, has a more accessible syntax and a truly badass standard library. And doesn't make you want to jump blindfolded off of tall buildings.
Skunkweb lets you combine the best of Python and PHP -- you create real Python classes to do the heavy lifting/DB accesses/app logic (and you can unit test those separately) without the PHP spaghetti code mess, and then you use Skunkweb's refreshingly sane blend-of-HTML-and-Python template language (contrived example -- need a list of usernames? It's this easy)<:import foo:>
to tie it all together. The win is that this way you can separate logic (standalone Python modules) from presentation (templated HTML/Python) in a much cleaner manner than other web development frameworks.
<table>
<:for `foo.Users.getSome()` u:>
<tr><td><:val `u.username`:></td></tr>
<:/for:>
</table>
In addition, it was built from the ground up for scalability (ok, the application server itself is probably slower than Apache/PHP, but I don't notice the difference, and you can use psyco or other methods to speed things up) and has caching and db connection pooling and other performance-oriented features built in.
I've been doing web development for nearly a decade, and Skunkweb has recently been my best-kept secret and a big competitive advantage. It's at the core of two companies I'm starting (one of which is a comprehensive online SAT prep course and is already profitable, the other which is earlier stage but angel-funded) It lends itself to clean and quick development and if it didn't have the stupid name (good luck convincing your boss to bet the farm on something with "skunk" in the name) it would have taken over the world by now.
Anyway, you heard it here first, folks. If anyone else out there is using Skunk, drop me a line (houston at mit.edu) because it would be nice to start a little community.
-fren -
Re:Opinions on Drupal
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.
-
Re:Dont Forget ZopeZope targets a very different space than Rails. It's always been a bit of a struggle for a programmer -- it tries to make certain things easy, and in the process makes other things very hard, or introduces very difficult magic. You can't get your head around Acquisition, no matter how you try it'll kick your ass periodically.
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.
-
Ruby marketing vs Cherrypy
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.
-
Re:Python Version of RoR
Similar ideas worth taking a look at for python:
http://www.cherrypy.org/
BSD Licence, also based on MVC style design. -
Python has CherryPy and Subway
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, CherryPy is another simple frameworkI played with Rails and liked it, but I am now trying to cut down on the number of programming languages that I use (trying hard to just use Java, Python, and Common Lisp) and even though it was fun working through a Ruby tutorial, I think that I am going to give Ruby a pass, at least for now.
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.
-
Libraries Comparison
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.