Debugging Pylons Code with Winpdb
For the past week or so I’ve been really digging into Python and Pylons, seeking a lot of things all at once: A creative outlet for long-unexercised programming appetites; new and potentially better ways to tackle the old problems than the mess of complex pain that Java has become; a test to see how my brain handles a lot of technical learning again. I could write about many of the aspects of this process, but the one that finally has gotten me to write out loud is simply this: I have to share what I’ve learned about debugging Pylons code since it was such a pain figuring it out (for lack of clear direction).
I’ll just say quickly that there’s a lot to like about Pylons, Python in general, and the feel of the Python world. I have friends I respect who love Ruby and Rails, but it just didn’t grab me and I was turned off by a lot of the feel from the community. My years in the Java world (10+) along with C++, C, and many other languages before that mean I start out with a slight disbelief that something so light and “script-like” can be expressive and powerful…but at the same time I know from experience that even VB can be very productive for certain tasks.
Since I’m simultaneously learning Python the language, Pylons the web app framework, SQLAlchemy for ORM, Mako for templating and some ExtJS for a rich UI and Ajaxing, there are many places where I really want to look at things as they are executing — I want an interactive debugger to learn with. The punchline is that Winpdb looks to be quite good, and can attach to a running Python app. The catch is that Pylons is typically launched in development with the paster command, as in:
paster serve --reload development.ini
…which runs the Pylons app and will reload the context if files are changed, automatically. But I don’t think Winpdb wants to launch a non-Python executable. So it turns out that you can insert a line like this:
import rpdb2; rpdb2.start_embedded_debugger('go')
…in a method of a controller. When that code is executed (e.g. by hitting a URL) the app will pause for a few minutes waiting for a debugger to attach to it. So go fire up Winpdb and do File -> Attach, which will ask for a password (should match whatever you used above, e.g. “go”) and you will then see the local instance, ready to receive you.
Note that Pylons does have some very nice interactive debugging support built-in, but I get a lot of comfort from being able to set a breakpoint in server-side code, attach to it (even remotely) and take a look around.
So far the biggest downside to all this coding fun is that I am staying up much later and sleeping less.
I will also say that I remember writing my first database-backed web apps in 1996 and in some ways it’s stunning that the issues are still fundamentally the same, 12 years later. We’ve got much fancier layers and presentation, but somehow I would have expected more to have changed.
