Slashdot Mirror
A Piece of CherryPy for CGI Programmers
An anonymous reader writes "IBM developerWorks is running an article outlining the strengths and offering some helpful advice on the Python framework 'CherryPy'. CherryPy uses the same concepts as CGI to bind a web server to a web application, but it improves performance and gains persistence across requests by handling all its requests within a single process."
This is nothing special. Just another framework that doesn't really do anything unique at all...
In the first few posts, I've seen a lot of relatively lacking-in-clue replies asking how CherryPy is different from ASP.NET, mod_python, FastCGI, etc. With most Apache-based web platforms, one process will handle many requests, but you cannot guarantee that every request will be handled by the same process: by default, apache starts multiple (possibly multi-threaded) servers, and creates and destroys them as necessary.
CherryPy, on the other hand, runs every request from the same process by using a thread pool instead of a process pool. This means that any global variables you change will be visible to any request. In many cases (keeping in mind memory restraints), you can share items in memory that would otherwise have to go through the database, which can help performance and make keeping track of state easier. Of course, multithreaded data sharing places its own demand on the programmer: the Python core is inherently thread-safe, but no programming language can protect you from race conditions and the like.
I've played around a little bit with CherryPy, and writing in it definitely feels Pythonic. It may still need some more development before it is fully mature, but it's something to at least keep an eye on.
(On a side note: I don't know how the IIS/ASP.NET process model works. It does let you store data across an application, but you are limited to a single Application hashtable, probably to be orthogonal to the Session and Viewstate objects and to reduce the likelihood that a programmer not experienced with concurrency would shoot him/herself in the foot.)
Friends don't let friends misuse the subjunctive.
I think people are looking at this the wrong way. I see a lot of posts saying "who cares? ASP is already like that!" or "You're supposed to have it in a single process anyway!"
What makes this cooler is that Python functions are exposed in the URL. Read through that IBM tutorial. It's fairly interesting. Put a function called hello() in your CherryPy application, and the return value of that function is displayed in your web browser when you visit http://address/hello
I don't know about you, but I think that's pretty cool. You could definitely do some interesting stuff with this, and I can see it saving a lot of time in the code-writing phase. And once you get your head wrapped around that concept pretty well, the design phase would probably get a lot shorter too. (Not to mention how much easier it would then become to add new features to the application.)
This is interesting for two reasons: Python frameworks are now catching up to things like ASP and PHP, but are doing some crucial things differently that might make it much easier/more powerful. I might start using this instead of PHP for small web apps that just need to talk to a database, and see how it goes from there.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
It says "All it does is connect the Web server to your Python code with as little fuss as possible. It doesn't make decisions about what other tools to use, ..."
And then in the very next paragraph, it says: "Instead of relying on Apache or another Web server, CherryPy runs its own small Python-based Web server."
No, no, no!
I love CherryPy as a way of routing requests to Python objects and functions. Rock on!
But look, I'm running like 20 wiki and 5 custom web apps and a few WordPress installations on my server.
And they are all plugged into Apache.
So, actually, in fact, CherryPy has now made some decisions about what tools I'm supposed to use.
Sure, I can forward requests from Apache to the CherryPy server, but that is yet another hassle, it is yet another thing to support and maintain and think about.
I wish instead that the CherryPy dev's had made it so there were multiple adapters to the CherryPy system.
All that said:
CherryPy is my favorite system for doing web apps in Python. I've used it, I've loved it, it's great. It does make programming WebApps "fun," which is perverse. So, it's succeeded.
But I strongly dislike how I have to do this funny Apache business to get it to run on port 80, or I have to give people weird 8080 addresses, like you saw in the article.
Another thing I dislike, is that it's kind of tricky to get it to do XML-RPC, in my experience. (Then again, that was 3 months ago. Perhaps things have changed now.)
(I just use AutoXmlRpcServer or AutoXmlRpcCgi for when it's XML-RPC alone, without a web side along with it.)
But again: CherryPy is my favorite, when there is no XML-RPC aspect, and when I don't mind the weird config stuff I have to do to get it to cooperate with Apache.
Using SQLObject is very popular with CherryPy users. CherryPy works with just about any templating system out there. This also makes it very easy to port from other Python web frameworks because you can use your existing templates.
Subway was created to use CherryPy, SQLObject and Cheetah templates in a very Ruby on Rails-like way, so you don't have to go through the 10 zillion decisions of what to use with CherryPy and tells you "what to do and where to put it".
I find CherryPy's URL traversal scheme a bit clunky -- since you connect up objects to each other via attributes, you can't see the hierarchy of your site. At least with PHP you can use "ls" to discover what your URL space looks like. Django uses a really neat scheme that binds a table of named regular expressions to callable handlers, e.g.
(r'^polls/(?P<poll_id>\d+)/$', 'myproject.apps.polls.views.polls.detail')
and the handler is declared as
def detail(request, poll_id)
...
-Brendan