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...
units.smile.face.width = "Miles"; smile.face.width = "10";
You are not the customer.
OK, enough with the silly Py names. PyCrust, PyShell, and now CherryPy, sheesh.
Regular CGI, mod_perl, mod_python, the newcomer Ruby on Rails, and now CherryPy. Granted, some webhosts handle the first four (even Rails) without any problems, but how many do we really need?
I suppose the answer is "as many as it takes" — whatever's easiest for some users will be utterly impenetrable to others, and it's good to have choice. But at what point does it start to become a burden to keep up with all these — either for programmers looking to keep their CVs up to date, or hosts wanting to stay current?
FastCGI anyone?
I have been doing that with python and perl for years. I can even run the CGI on multiple different hosts with one webserver.
that's a referral link in the parent post. To be honest, I'd recommend them anyway, but it's probably best to disclose it.
I'm not a py programmer at all, but seeing as numerous single-process dynamic web platforms exist (PHP, JSP/Servlets), whats w/ all the hype? Maybe ppl are just happy to be able to use python for web apps?
-m
I can't remember the last time I forgot anything.
CGI's my cherry pie.. A cool drink of water...
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.
Python is a great language, but my worry is about security. I would think that given the previously mentioned cool features, this app would have more security worries than your average all-in-the-same-process cgi extenders.
I'll got ahead and put in a plug for Nevow here, another web framework that is based on the EXCELLENT Twisted framework.
If you're doing any sort of network programming in Python, you need to look at Twisted.
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.
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, so you're free to pick a templating system, database mapper, or other tool on its own terms.
This is kind of a problem though because I actually need a templating system, database mapper, and some other tools. I have some such tools in Perl, but I obviously can't take these with me into Python.
So I am wondering. Were one to use CherryPy, what would be logical tools to build on top of it with? If I need to be able to take objects and convert them into lines in a database or HTML for display or HTML forms for editing or whatnot, what would be the logical things to plug in on top of CherryPy to provide this?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Actually I think CherryPy and Zope have been around a while before Ruby on Rails. And speed wise Python kicks Ruby's ass for now.
And actually I don't know of any java frameworks that don't require tons o' xml flinging to get up and running. Please feel free to enlighten me.
Interactive Visual Medical Dictionary
But of course, if IBM says it's new, well it must be ;-)
Okay, I checked, and I exagerrated a little bit, the earliest CVS version on mod_fastcgi.c is:
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
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
If you're "running like 20 wiki and 5 custom web apps and a few WordPress installations" on your server then you shouldn't be intimidated by the 2 or 3 lines it takes to forward requests to the CherryPy server.
Get a grip.
...how about a piece of ApplePy?
I'm assuming you didn't read the article, because it explains that CherryPy doesn't just call whatever function is passed in the URL. The programmer has to explicitly expose his functions to the CherryPy server instance. Otherwise, they won't be called. So unless for some reason you @cpg.expose rmdir or kill or any other system function (which you would obviously never do) this isn't an issue.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
It's:
I just plain don't like any of that stuff. None of it.
I'm not a sysadmin; I'm lucky to have cobbled together my 20 wiki, 5 custom web apps, and a few WordPress installs. I dread upgrading my Wordpress blogs, one of which isn't even working right now, and has been custom hacked. Something about not being able to connect with the MySQL db for some reason, I don't know. I don't even care at this point. I dislike diddling with stuff.
Gimme as few pieces as possible. Don't make me think about security, don't make me make things automatically start at boot time, plug into my existing framework, yadda yadda yadda.
Gimme gimme gimmy!
Man this is bad but when I read the header to this article, the first thing that came to mind was Warrant ...
Beeep, wrong
Python is not based on any "java ideal", and everything in python is indeed an object, a module is an object, a function is an object, and "1" is an object by itself.
And it can't be compiled, it's a purely interpreted language, it's merely loosely syntax-checked and translated to bytecode (not compiled mind you, that's several steps under java). Some utils write machine code at "compile time" (Psycho), but it's not built in the base language in any way.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
I don't know much about Python, but I doubt that emerge's slowness comes from Python. It's probably doing a linear scan of something that should be indexed more intelligently. Or maybe it's opening a huge number of files.
A similar thing applies to web apps - a slow web app is usually due to high-level design errors, not a slow scripting language. A lot of web apps spend most of their time in database calls. When an app is blocked on I/O, it's just as fast in Python as in C, much like a Porsche stuck next to a Yugo in traffic.
Perl is not exactly a speed champ compared to C, but many snappy web pages run on Perl because the amount of computation involved in sending the web page is relatively small. Is Python substantially slower than other scripting languages?
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
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.
--- Hot Shot City is particularly good.
It's a very new project, so I don't think it's been used in any Python framework yet. But it would probably be applicable to quite a few of them (perhaps including CherryPy).
she's my cherryPy looks just like a stand alone app but its a cccccccggggggiiiiiii...sweet cherryPy
http://www.vanillaafro.com - take me seriously and I will shoot you