Thanks, that's the information I was looking for - an explanation of what the actual pylons code (that is not part of the thrid party libraries) is doing.
I guess that means routes can be taken out if I remove the routes middleware and use my own url_for (which I was just about ready to do). So in your assessment a simple hello world on pylons using cherrypy instead of paster (that is my current config) is going to be as fast as just as an equivalent cherrypy (or pretty close, but not twice as slow) ? P.S. - mod_wsgi is a hack, it's an unstable and unscalable architecture to embed the app server in the web server. And using daemon mode makes even less sense as using apache+mod_wsgi as a process monitor for the app server (it's better to use a dedicated and specialiazed monitoring) as well as a proprietary communication protocol when we already have http and fcgi, is silly. On Jan 11, 12:45 pm, "Mike Orr" <[email protected]> wrote: > On Sun, Jan 11, 2009 at 5:47 AM, Lawrence Oluyede <[email protected]> wrote: > > > On Sun, Jan 11, 2009 at 2:33 PM, Tycon <[email protected]> wrote: > >> Pylons has some useful things in it, however most of them are actually > >> independent packages that pylons just depends on. The definition of a > >> meta-package - in the context of Debian's APT, for instance - is a > >> package that doesn't have any content of its own, but it's simply a > >> list of dependencies on other package, so that users can get all > >> those other packages by installing the meta-package. > > > That's where META PACKAGE definition does not apply to Pylons. Pylons > > has source code, glue code and utility code. Hence is hardly just a > > meta package. Yes, you are not constrained to use the default > > packages, but that's not being a meta package, that's being a > > pluggable architecture. > > > Debian metapackages are just a list of dependencies to install and a label > > Pylons is everything that's in the Pylons package itself rather than > in dependencies. The essential part is the PylonsApp class and the > application template. The decorators are peripheral; they were just > thrown in as convenience tools. > > Pylons' philosophy is to use third-party distributions as much as > possible. But certain features were not available in any third-party > distribution, so they had to be written from scratch. A Routes-based > dispatcher, for instance. A fully WSGI request manager. > > > > >> I considered the basic strength to be the HTTP server which comes from > >> Paste which I guess together with some other sub-modules provides all > >> the HTTP request processing. But then I found out about CherryPy 3 and > >> confirmed it gives much better performance and a dispatching > >> architecture, so what exactly is left in pylons ? > > > Paste and CP3 are not meant to be used in the deployment phase. I > > really don't care about who's fast during development mode (either > > Paste or CP3 or something else), I do care that mod_wsgi in Apache or > > nginx or lighttpd are solid. > > >> Maybe Routes, but if the only route you need is "controller/action/ > >> id" (which I think CherryPy supports) dispatch is enough, then we > >> don't even need routes fancy (and most likely wasteful and expensive) > >> mapping. > >> Mako, SQLAlchemy, and FormEncode are all great but can be used > >> independently. > > You can use CherryPy with Pylons. It's just a small change in the > [server] section of the ini file, which you can find in the list > archive and maybe on the wiki. Pylons-on-CherryPy is reported to be > better in high-traffic deployments than Pylons-on-PasteHTTPServer. > (Although mod_wsgi may be faster still?) > > If you don't want Routes, plain CherryPy may be a good alternative to > Pylons. You can certainly use Mako, SQLAlchemy, and FormEncode with > it. > > The "Pylons Execution Analysis" may help explain what's going on and > which module is responsible for what. (It was written for 0.9.6 so a > few things like templating have changed, but most of it is still > accurate.) > > http://docs.pythonweb.org/display/pylonscookbook/Pylons+Execution+Ana... > > Basically, although the Pylons application *template* is specific to > Pylons, a created application is the user's code, and when it runs > certain portions are not under "Pylons'" control. > > So, you run "paster serve", and it reads the config file and > instantiates the server. This is all Paste, not Pylons. The server > may be multithreaded or multiprocess (or mod_wsgi, in which case most > of this is skipped). The application advertises a Setuptools entry > point for myapp.config.middleware:make_app(). Paste uses this to > instantiate the Pylons app. > > make_app() -- the users' code -- instantiates a PylonsApp and adds > some middleware around it. There's some trickery in that the > configuration is put into a Pylons config object, and PylonsApp looks > in the config object to find out where the application is. (This was > done to keep boilerplate code in the users' modules to a minimum.) > > When a request comes in, Paste calls the PylonsApp as a WSGI > application. The PylonsApp does routing to determine the controller, > instantiates it, and calls it as a WSGI application. The controller > is user code but its base class is Pylons code. The base controller > chooses an action method, looks at its signature to determine which > arguments to call it with, calls it, and incorporates the return value > into the WSGI response. That's about all Pylons does, besides > managing the context variables (request, c, etc). > > CherryPy is simpler but less flexible. I"m taking pure CherryPy here, > not Pylons-on-CherryPy. That simplicity may increase runtime speed, > but maybe not enough to be noticed. The Routes overhead is basically > a few method calls. The context variables each add one call per use > plus a couple per request (because they are proxies). > > CherryPy 3 does support Routes as an option, not that you would care > since you're trying to avoid overhead. > > The main difference between Pylons and CherryPy is philosophical. > CherryPy grafted WSGI and Routes on as options. Pylons was designed > around them in the core, and doesn't include legacy alternatives. > > -- > Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
