Comments on: Error Reporting in WSGI Applications

By: Massimo

Massimo — Fri, 25 Jan 2008 15:25:16 +0000

If you download the web2py source code instead of the windows/mac executables, you can deploy it as any other python framework. In fact web2py is wsgi compliant, packages the paste httserver (same as pylons) if you want to use mod_proxy, and a wsgi handler like Django if you prefer mod_wsgi. You can install any python module using easy_install and import it from models/view/controllers as you would in Django or Pylons. web2py allows you to bytecode-compile your controllers/views so that 1) no parsing of templates is done in production mode, and 2) you can distribute your apps in semi-closed source; this is why it bypasses the normal import for its own controllers. A small prize to pay for a much faster framework.

By: Armin Ronacher

Armin Ronacher — Mon, 21 Jan 2008 19:22:11 +0000

In general I’m not a framework lover, even though I’m happy Django user. Mainly because I have a couple of use cases I can solve with Django and because the Django developers do a very good job at keeping the source clean, readable and maintained.

When I looked at the web2py sources I stopped looking at it pretty soon when I found out that it’s bypassing the python import system for controllers and models, that it comes in a nonstandard distribution I can’t deploy on a server that easy and that it’s reinventing the wheel everywhere.

For custom applications I don’t want to miss SQLAlchemy any more or all those template engines available for Python. So no, for things I have to bootstrap fast and quickly I would chose Django because of the community and the number of developers, and for custom applications I go with Werkzeug, especially because I can fix it when it breaks ;-)

By: Massimo

Massimo — Sun, 20 Jan 2008 07:09:18 +0000

… another misconception about web2py is that you have to use the web interface for development and for database administration. You can but you are not forced to.

By: Massimo

Massimo — Sun, 20 Jan 2008 06:46:52 +0000

I would like to make two corrections: 1) You say that web2py “files tickets for tracebacks in the database”. No. web2py files tickets for any error that occurs and that is not explicitly catched by the application, including db tracebacks. 2) You also say “it’s a terrible idea to put that data into the very same database all your application data goes (what happens if the DB is down?” I agree and web2py in fact does not do that. web2py tickets are stored in files and they can be accessed even if the db is down. Every app has its own seperate ticketing system provided by web2py.

You also say that you would not use web2py for countless reasons. It would be helpful if you were to list those reasons. Perhaps some of them are consequence of misinformation and I could try convince you that, in fact, you should use web2py. ;-)

One common misconception is to assume limitations because of the GPL license. If you read the web2py license carefully, as long as you do not copy web2py code into your web2py app web2py makes no claims on your app and you can even distribute it in closed form (something that web2py builds for you) and charge for it.

By: Georg

Georg — Sat, 19 Jan 2008 09:41:16 +0000

BTW, the documentation for logging has recently been enhanced by a tutorial section, thanks to a GHOP student, see http://docs.python.org/dev/library/logging.

By: Armin Ronacher

Armin Ronacher — Sat, 19 Jan 2008 00:38:36 +0000

That’s very true. But in a production environment the calls to the actual logger can be reduced to the cases where you actually log an error or exception. For example you can create methods for log / info / warn or whatever and if __debug__ is False you replace them with a no-op lambda.

My point with that post was mostly to not reinvent exception reporting when the stdlib can do that. And that one logger.exception call in the very last except of your WSGI application won’t harm the performance of the application at all.

By: Robert Brewer

Robert Brewer — Fri, 18 Jan 2008 23:02:14 +0000

> I don’t know why so many people miss it or just don’t use it…
> Why is it so good? It’s extensible and configurable.

That’s also why it’s so bad: it’s so extensible and configurable that’s it’s far too slow for high-performance websites. So please, when you make the latest and greatest web framework, go ahead and add support for the logging module, go ahead and make it the default, but make it easily overridable at the same time.