blog: Minor Pylons Annoyances

I've been working a lot with Pylons recently, and WSGI in general. My previous experience with WSGI-compatible frameworks is pretty much just Django, although I've made efforts to make use of the WSGI aspects by swapping out some middleware and the templating language. Basically, though, Django is the yardstick I have to measure by, although, as I get more experience with Pylons and it's components, that will slowly change.

Pylons is a nice system, but there are a couple of things which surprised and frustrated me. The first is that the configuration file is - a config file. I greatly preferred Django's use of an actual, runnable Python file as a settings file. Parsing a file always adds a layer of abstraction that, in this case, isn't needed. Yeah, for Apache, I can see the need to have a plain-text configuration file; but for a system using Python, you have a great parser built right in. It's an interpreted language... so interpret! It's also considerably easier for me to see where things are "coming from" with a Python config file; the Pylons config file, because of that layer of unneeded abstraction, leaves me often confused... is it returning strings, or instances of objects, or instances of config objects, or something else altogether? The simplicity of staying in Python code is lost.

The second thing that scares me is the integrated web-based debugger. Yeah, it is powerful, and very, very useful. Unfortunately, it's completely, totally dangerous¹, maybe even too dangerous for a developent environment. Django, on the other hand, doesn't offer any sort of AJAX debugger, but instead has a debug mode that won't show more than a few lines of code and the local variables. The debug mode can be turned off, but if you aren't embarrassed by others seeing your source code, you can also just leave it enabled; there won't be anything overly dangerous displayed. For this site, for example, the convenience of being able to leave debug enabled in Django outweighs the extra convenience² of getting an ajaxy shell in Pylons. Better than both, of course, would be to have both; a tri-state Boolean field for the debug flag, either True (Pylons Debug), False, or Kinda (Django Debug). :)

The third one is that documentation simply isn't as good³ for Pylons. I'd go so far as to say that someone trying to learn Python web applications should start with Django, even if they will eventually use another framework. The documentation is that good - and good documentation is that important. Learning Django first gave me a very clear conceptual model of what's going on. Django has some magic, but it's not at all complex; I was able to swap out the templating language layer without major hassle only a couple months after touching Django for the first time. On the other hand, because Pylons consists of so many discrete parts that I honestly have little idea how each works, until I work extensively with each component. I'm still learning what's going on with SQLAlchemy, and the tracebacks mean nothing to me yet - but even once I know the workings SQLAlchemy, that'll have little to do with anything else. In contrast, although Django has loose coupling, it is still consistent; you can learn "Django" concepts that will apply to each individual layer as well as to the whole. I'm finding that I can't learn "Pylons" concepts that will apply to all layers of Pylons, unfortunately.

That being said, we're going to using WSGI a lot, and it looks like I may have the chance to fix/improve some of these things on our internal implementation. I still need to learn WSGI at a more intimate level.

Lastly, I got my first real introduction to Pylons from a Google Tech Talk titled "Reusable Web Components with Python and Future Python Web Development." It's definitely worth checking out if you have an hour of downtime to kill.