Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

A Piece of CherryPy for CGI Programmers 193

Posted by ScuttleMonkey from the making-web-programming-easier-to-stomach dept.
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 discussion has been archived. No new comments can be posted.

A Piece of CherryPy for CGI Programmers More

A Piece of CherryPy for CGI Programmers

Comments Filter:

  • You mean... (Score:5, Insightful)

    by nxtw ( 866177 ) on Sunday August 21, 2005 @07:41PM (#13368835)
    it runs a web application in a signle process, like ASP, ASP.NET, and most likely other technologies have been doing for some time?

    This is nothing special. Just another framework that doesn't really do anything unique at all...

    • Didn't anybody tell you? Things that aren't unique in any way at all are totally in these days. Really, hop on the bandwagon and get rich from a piece of shit like the rest of the world.

    • Re:You mean... (Score:3, Insightful)

      by Jerf ( 17166 )
      With the staggering number of frameworks available, "unique" is an awfully high bar. I'm not sure a standard that eliminates all frameworks from consideration is a valuable one.
    • Umm, nxtw, you must have missed my memo! In the memo I told you to be "surprised" and "elated" about this "new" "technology"! I need to see you in my office, first thing Monday morning.

      Oh, and until we speak, you should pretend to be excited about a "new" "technology" that is single threaded and susceptible to the whole process crashing because the _one_ thread it uses dies.

      • Uh, whoa. Hold on there, chief. I didn't, shall we say, "read the article", per se, but I can tell you right off the bat that this "new technology" is not single-threaded, it's just carried on from one process. Maybe you'd like to call them "light-weight processes", but these days, one process can host a myriad of threads, each doing their own thing. What was that about being a senior programmer, now?
        • Uh, whoa. Hold on chief. Did you even read my reply to someone else (poster nxtw)? It was a JOKE.

          What was that about being a senior programmer, now?

          What was that about having an IQ above 80 that would help you understand someone being facetious [reference.com] (I know, it is a big word for you) vs. being serious?

          Oh, and thank you "Captain Obvious" for telling us that:

          these days, one process can host a myriad of threads, each doing their own thing

          I really wish /. would require a simple IQ test before someone coul

          • Oh, and thank you "Captain Obvious" for telling us that:

            these days, one process can host a myriad of threads, each doing their own thing

            Guess what I was being? That's right, facetious [reference.com]! Congratulations.

            I only replied because I didn't find your comment very funny, and I don't like people who put pretentious things like "Senior Programmer" in their signature, if I wanted to know what your title at work was, I would ask you; otherwise, I'll judge what I think of you by what you sa

            • don't like people who put pretentious things like "Senior Programmer" in their signature

              Oh, you just like people who put "witty" sayings in their sig such as yours?

              /* Imma squeeze out some more karma by putting a C-style comment in my sig */

              Heh, heh, heh. That is just great. I bet your just "the" elite /. user aren't you? Boy, I wish I could have come up with a great sig like yours! I bet your some 133t hacker huh?

              Obviously, you're not a Senior Grammatist

              Ahh, yes, your sig is a well structured a

    • CGI's my cherry pie.. A cool drink of water...

    • Re:You mean... (Score:3, Insightful)

      by damiangerous ( 218679 )
      At no point in the article does this claim to be "unique" in any way. Quite the opposite, in fact. It acknowledges that there has been no shortage of these frameworks. The only way in which it's "unique" is that its Python. Basically, it exists simply so that people who know and enjoy Python can stick with it.
      • Plus, it's been around for quite some time, as have been many other Python web frameworks (look for the Python framework shoot-out if interested). I evaluated it more than a year ago but didn't go with it.

        Anyway, what's "hot" in Python for web currently is Django.
    • ... but it's got a neat name!!

    • Re:You mean... (Score:5, Interesting)

      by jma05 ( 897351 ) on Sunday August 21, 2005 @09:38PM (#13369298)
      CherryPy is nothing like ASP, ASP.NET. The script you write is EVERYTHING. You don't need a web server like you do in ASP/ASP.NET. It is the web server with your code in it. I have been using CherryPy for a while. What is nice about it is that for simple things, it justs steps out of the way. There is very little framework code in my apps and they just feel like console programs.
      • I like CherryPy because it is very lightweight and doesn't rely on an external webserver. It's especially well suited to tasks such as web-based system managers. Afterall, it really sucks to enter changes into your web-based web server configuration manager only to find out that your changes broke the web server so you can no longer configure said web server. I converted my existing mod_python scripts to CherryPy and have so far had very good luck with it.

        Python is a much better language for writing complex

  • Obligatory (Score:5, Funny)

    by Limburgher ( 523006 ) on Sunday August 21, 2005 @07:42PM (#13368837) Homepage Journal
    units.smile.face.width = "Miles"; smile.face.width = "10";

    • Re:Obligatory (Score:2, Insightful)

      by Anonymous Coward
      I hate to be anal about a joke, even if it doesn't really qualify as one, but shouldn't that be more like this?

      face.smile.width.units = "Miles"
      face.smile.width = 10

  • PyDie (Score:2, Funny)

    by Anonymous Coward
    OK, enough with the silly Py names. PyCrust, PyShell, and now CherryPy, sheesh.

  • So, we now have (Score:3, Insightful)

    by TDScott ( 260197 ) on Sunday August 21, 2005 @07:57PM (#13368888)

    Regular CGI, mod_perl, mod_python, the newcomer Ruby on Rails, and now CherryPy. Granted, some webhosts [dreamhost.com] 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?

  • Umm.. (Score:3, Informative)

    by Anonymous Coward on Sunday August 21, 2005 @07:57PM (#13368891)
    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.

    • Re:Umm.. (Score:2, Interesting)

      by dotgain ( 630123 )
      Sure, FastCGI is great, I agree. But, even after all these years "Fast" and "Python" still aren't allowed to be used in the same sentence, hence CherryPy. Mark me Troll, that's fine, but please tell me: Am I the only one that thinks CGI in python is insane because it's the all round slowest-to-run programming language about? Sure it's nice to write and easier to read than most, but for any program you end up running 100 times more often than you write it, choose somthing else.

      Can anybody show me that Py

      • Plodding Python? (Score:3, Interesting)

        by crucini ( 98210 )
        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 nex
      • See this, computer languages shoutout benchmark [debian.org] Bigger is better, python is at 17, a few places behind C, perl is at 10. You wouldn't disregard perl when it comes to web frameworks, right? I don't know about emerge, or for example, up2date from fedora, but python programs don't have to be slow. I'm using zope and plone, and, for their complexity, they're fast enough. Another example: the Battlefield game series use python as internal scripting language.
        • Did you read the top of that page? It's supposed to be a joke...

          "What fun! April Fool's Day all year long! Can you manipulate the multipliers and weights to make your favourite language the fastest programming language in the Shootout?

          And remember, languages that implement more benchmarks will move to the top of the list, and those with many missing benchmarks will stay at the bottom!"

          That said, in the direct comparison there are no places where perl uses less memory or CPU than python, so you can't fudge
      • Python is faster than perl. And its an order of magnitude faster than ruby, and rails seems to be giving everyone a permament boner lately.

        Frankly I don't think python is a contender for CGI programming. Nor do I think perl or any other interpreted language is. Stop using CGI, its 2005 for fuck's sake.
      • Ok, I'll reply.

        Python is fast enough for most applications, and it has improved significantly in the latest releases, 2.3 and 2.4. It's not much slower than perl and is a much nicer language, IMHO. I've used it on countless projects without problem or performance issues.

        If performance is your primary concern, you wouldn't be using python, and you wouldn't be using CGI obviously so the question is not so relevant, I think.

        As for emerge, it's slow response comes from the non optimized way it scans a databas
  • 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
    • Probably... Personally I love Python, and one of the things I love is that it's still being developed. You can actually suggest something and see it implemented in the language. You can probably do that in many more, but all the others I know have been standardised. Plus it has all the other great stuff which makes it my first choice for anything.

    • Re:Give me a reason to use this (Score:5, Interesting)

      by Nasarius ( 593729 ) on Sunday August 21, 2005 @08:12PM (#13368947)
      There are already efficient ways of using Python for web apps. FastCGI and mod_python, for example. I'd like to see benchmarks for this new one.
  • 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.)
    • 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.

      ASP.NET uses a single process for each application. Every request is processed by the sa

    • I'd say the counterargument to this is that:

      1) python multithreaded scalability is limited by the global interpreter lock.

      2) With a multi-process model you can use memcached to cache stuff in memory without going via the DB. Additionally, with this architecture horizontal scaling is also possible.

      3) A multi-process model is pretty robust. If one process dies, apache restarts it. If your application, or the app framework etc. suffers from a memory leak, you can configure apache to let each process handle onl
    • ... , you can share items in memory that would otherwise have to go through the database, ...

      Like with shared memory? But shared memory also works with multiple processes. And if you've more than one webserver (scaling and stuff) you still need a central data storage, like a database or a simpler session storage (i.e. msession).

      b4n

  • People are looking at this the wrong way (Score:5, Interesting)

    by sean23007 ( 143364 ) on Sunday August 21, 2005 @08:26PM (#13369015) Homepage Journal
    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 [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.
    • >> Python frameworks are now catching up to things like ASP and PHP

      That's wrong on so many levels. For starters, ASP (assuming you mean ASP.NET) is lightyears ahead of anything python simply because it gets compiled into machine code before it's executed and runs "closer to the iron" (and therefore blows the doors off anything interpreted). I could name five dozen other reasons why ASP.NET and similar Java based frameworks are better, but I don't want to waste time. There's google, you can find it you

      • People are looking at this the wrong way (Score:4, Interesting)

        by darekana ( 205478 ) on Sunday August 21, 2005 @09:20PM (#13369240) Homepage
        Actually I think CherryPy and Zope have been around a while before Ruby on Rails. And speed wise Python kicks Ruby's ass [debian.org] 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.

      • "is lightyears ahead of anything python simply because it gets compiled into machine code"

        Actually,

        .NET introduced a new programming language environment that compiles all source code into an intermediate language. .NET languages are compiled into the Microsoft Intermediate Language (MSIL), which is executed by the Common Language Runtime (CLR) software in the Windows computer. The MSIL is similar to Java's bytecode, except that whereas Java is one language, .NET supports multiple programming languages...

      • For starters, ASP (assuming you mean ASP.NET) is lightyears ahead of anything python simply because it gets compiled into machine code before it's executed and runs "closer to the iron" (and therefore blows the doors off anything interpreted).

        Ok so you're code is running faster. And that brings you? Nothing. You're code is just waiting faster for data from the network or the database or the filesystem. If your code is good it doesn't matter if it's written in PHP, ASP, Python, Perl, Ruby, ... because it's a
      • "ASP.NET is lightyears ahead of anything python simply because it gets compiled into machine code"

        Machine code, yes. Only it is machine code ( bytecode ) for the CLR ( .NET's VM runtime ). Am i wrong or isn't it just when that bytecode gets loaded and handled to a JIT ( just-in-time ) compiler that it gets actually compiled to native machine code?

        BTW, i worked about a year on a system upgraded from ASP ( interpreted VBScript ) to ASP.NET ( bytecode compiled C# ). We wrote it from scratch, and only used t
    • > 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]

      Rails and Struts already have this feature.

      (Of course, for Struts you need a some XML for every class you want to act this way.)
    • I can see it now.

      http://www.site.com/rmdir [site.com]
      http://www.site.com/mke2fs?/dev/sda [site.com]
      http://www.site.com/kill [site.com] `pidof httpd`

      • Re:rm -Rf (Score:3, Informative)

        by sean23007 ( 143364 )
        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.
    • Great, so it's vulnerable to mass injection attacks. You COULD do this in Java Reflection. But you wouldn't. Ever.

    • Python frameworks are now catching up to things like ASP and PHP

      While Python web programming has some issues, "catching up" isn't really how I'd describe it. Even in the most basic of Python frameworks you get more expressive power than in ASP and PHP. You also get equivalent performance to PHP (I can't say much about ASP -- but Python is fast enough which is all that matters). In terms of expressiveness Python beats the pants off PHP, Visual Basic, C#, and Java. There's no "catching up" there at all,

  • Cool! (Score:5, Interesting)

    by smoondog ( 85133 ) on Sunday August 21, 2005 @08:39PM (#13369063)
    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.

    • Re:Cool! (Score:4, Interesting)

      by hoka ( 880785 ) on Monday August 22, 2005 @03:13AM (#13370170)
      What I've encounted with Python is the overwhelming lack of crypto, not necessarily a lack of "security" (I use that term loosely here). What stems from the lack of good default crypto is a sense of a lack of security. For example, the Python SSL implementation has no certificate verification, which is a huge problem for anybody who wants to do any client work. There is also a complete lack of support in most libs for servers (https server? secure xmlrpc server?). This means that you can only half-ass the client side, and the server side is non-existant. While I havn't looked at the framework, I'm hoping that they implemented extra features into the system that makes it a bit better of a choice for security reasons. Right now I'm having a hell of a time trying to get some basic solid crypto security going over xmlrpc.

  • Nevow (Score:5, Informative)

    by kevin_conaway ( 585204 ) on Sunday August 21, 2005 @09:05PM (#13369173) Homepage
    I'll got ahead and put in a plug for Nevow [nevow.com] here, another web framework that is based on the EXCELLENT Twisted [twistedmatrix.com] framework.

    If you're doing any sort of network programming in Python, you need to look at Twisted.

  • " All it does is..." (Score:5, Interesting)

    by LionKimbro ( 200000 ) on Sunday August 21, 2005 @09:08PM (#13369187) Homepage
    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 [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.

    • Wow, dude. Chill. (Score:4, Insightful)

      by jbellis ( 142590 ) <jonathanNO@SPAMcarnageblender.com> on Sunday August 21, 2005 @09:50PM (#13369337) Homepage
      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.
      • It's not just the 2 or 3 lines in the Apache server.

        It's:
        • The 2 or 3 lines in the Apache server.
        • Learning where in the Apache documentation those 2 or 3 lines are, and familiarizing myself with them.
        • Debugging those 2 or 3 lines, fiddling with Apache a bunch.
        • Figuring out the details of where the CherryPy server is going to run, with what priviledges, with what permissions on what directories.
        • Figuring out how to configure the CherryPy server.
        • Figuring out how to make the CherryPy server automatically start when

        • Re:Wow, dude. Chill. (Score:2, Insightful)

          by Anonymous Coward
          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 [cherrypy.org]

    • Re:" All it does is..." (Score:2, Funny)

      by Anonymous Coward
      Perhaps.

      You could put more than one thought.

      On each line.
    • The Python WSGI spec (PEP 333 [python.org]) is trying to address exactly this issue. And I agree it's an issue -- I maintain quite a lot of Python applications (not in CherryPy, but same basic setup) and it can be really annoying. CherryPy supports WSGI, though its WSGI support isn't perfect (but they're aware and working on it).

      Relatedly I just released Paste Deploy [pythonpaste.org], which is also intended to address these issues. It's just a small piece that will only be useful given more infrastructure support, but I'm optimist

    • 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

  • Seems only useful if you already do Python CGI. (Score:3, Insightful)

    by mcc ( 14761 ) <amcclure@purdue.edu> on Sunday August 21, 2005 @09:13PM (#13369206) Homepage
    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?
  • ... FastCGI which has had a several [sourceforge.net] python [lysator.liu.se] modules [suxers.de] for about 10 years...

    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:

    Revision 1.1 / (download) - annotate - [select for diffs] , Tue Sep 16 15:38:22 1997 UTC (7 years, 11 months ago) by stanleyg
  • Easy as pie?

  • django! (/. missed the hype train) (Score:5, Interesting)

    by brendano ( 457446 ) on Sunday August 21, 2005 @09:42PM (#13369313) Homepage
    The big thing in python web programming right now is the introduction of Django [djangoproject.com], a mature RAD framework that shares lots of features with Rails. It's got a lot going for it; it'll be interesting to see how things turn out.

    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)
    ...

    ...so that requesting /polls/13/ maps to calling detail(request, 13). Here's more about it... [djangoproject.com]

    • If we're talking about URL management, an interesting Python project is a port of Rails' Routes [groovie.org]. This is notable in particular because it is reversable -- you can both unpack a URL to a controller and set of arguments, and pack a controller and set of arguments back into a URL.

      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).

  • .. I need to read more.. but this sounds like apache and tomcat interoperation.. tomcat being one process to handle the jsp requests...

    Why not just embed the python interpreter in an apache module ....

  • ...how about a piece of ApplePy?
  • Man this is bad but when I read the header to this article, the first thing that came to mind was Warrant ...

  • I run a project that aims to be a java port of CherryPy. Supports all free vms and is very lightweight.

    OOWeb [sf.net]

    /plug

  • Quick fix for 2.1 (Score:3, Informative)

    by mav[LAG] ( 31387 ) on Monday August 22, 2005 @10:11AM (#13372028)
    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 [cherrypy.org].

  • she's my cherryPy looks just like a stand alone app but its a cccccccggggggiiiiiii...sweet cherryPy

Slashdot Top Deals

IOT trap -- core dumped

Close