A Piece of CherryPy for CGI Programmers 193
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."
Give me a reason to use this (Score:2, Interesting)
-m
Re:Give me a reason to use this (Score:3, Interesting)
Re:Give me a reason to use this (Score:5, Interesting)
People are looking at this the wrong way (Score:5, Interesting)
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 [address]
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.
Cool! (Score:5, Interesting)
Its all in the marketing .... (Score:1, Interesting)
It is sad to say, but at the moment the war as to which is perceived as being the better Python framework for web applications is being won more on the marketing side than on the particular technical merits and quality of implementation.
There are some people out there who are developing some really quite interesting stuff based on inovative ideas and who are producing good quality code as well, but in many cases, although they may result in a better experience as far as developing a web application, because they don't have the associated marketing that some projects have, they get passed over and the projects never get developed that extra step to turn them into something awesome.
The ultimate in hype for Python web frameworks of late has been Django. It has been getting a huge amount of mind share by comparing itself to Ruby on Rails. The last time I looked they still hadn't actually made an official release.
In summary, if you want to build a successful Open Source project, don't start by writing code, do what any commercial business does and ratchet up the hype through marketing and promise the world. Do that and you will be almost certain to get lots of people to help you with the code once you do start.
" All it does is..." (Score:5, Interesting)
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 [taoriver.net] and 5 custom web apps and a few WordPress [wordpress.org] installations on my server. [taoriver.net]
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 [python.org] or AutoXmlRpcCgi [python.org] 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.
People are looking at this the wrong way (Score:4, Interesting)
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.
Re:You mean... (Score:5, Interesting)
django! (/. missed the hype train) (Score:5, Interesting)
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)
...
Re:Umm.. (Score:2, Interesting)
Can anybody show me that Python is a realistic contender for CGI - or for that matter - any programming? I used to subject myself to a Linux distribution called Gentoo [gentoo.org] whose package mismanagement system, Portage, is mostly if not entirely done in Python. I found that for compiles of many small packages, we spent about as many CPU seconds on 'emerge' itself than we did building. Running 'emerge' on something old and spluttery like a sparc32 is just not the done thing. You've got probably 30 seconds before you've got any indication that the program has validated your input and started processing at which point you find something else to do.
Re:Wow, dude. Chill. (Score:3, Interesting)
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!
Re:You mean... (Score:1, Interesting)
Re:Cool! (Score:4, Interesting)
Plodding Python? (Score:3, Interesting)
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?
Re:People are looking at this the wrong way (Score:3, Interesting)
Re:django! (/. missed the hype train) (Score:3, Interesting)
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).
Re:Cool! (Score:1, Interesting)