Python: WSGI, templating engines, and the C API
News, Technical, Photography ·Sunday December 19, 2010 @ 00:55 EST (link)
I set up WSGI on my web server (Apache, with mod_wsgi). I believe the last time I checked the WSGI specification hadn't even been updated for Python 3 (due to the Unicode changes). The major web frameworks (such as Pylons, CherryPy, Django, and Twisted) don't have stable ports yet, but most have a branch or some initial work, tests passing, etc. I set up .py files to be handled by WSGI and installed Mako and Jinja2 as templating engines but settled on Mako as it's a little more powerful than Jinja2. That also means it lets you do perhaps more than a templating engine should, but it's easier to self-restrict when using a more powerful engine than extend a limited one. Perl's Template Toolkit, which I used with mod_perl elsewhere on the site, is just the right level of power for templating; supposedly it was an inspiration for Mako (which replaced the now obsolete Myghty).
I ported my pH parser from Perl (XS and C++) to Python's C API. This was my first use of the Python C API, and it went quite well. The Python/C API Reference Manual and Extending and Embedding the Python Interpreter were my primary sources, and a vast array of web searches (many of which ended up at Stack Overflow, a great merit-based programming Q&A community). One problem I had was instantiating a Python (non-C) object that I used to represent elements in the parse tree. I started with PyObject_New and added PyObject_Init, and found very little help online but some examples did lead me to try calling PyObject_CallObject on the PyTypeObject, which did the right thing—constructed the object (invoking the standard __call__ implementation for classes no doubt).
I also got to use distutils, which I'd avoided so far by having my Python modules in separate tree added to the module path; but C modules need a proper build and install. It was, fortunately, quite easy to do, even with __init.py__ and a combination of Python and C modules in the pH.parser package.
My current project, after these segues, is to develop a decent Javascript embedded image slider/viewer. I may use it to improve the new (internal, probably won't be public) "photo manager", which I'll use to improve tagging and organization that I was hacking on sporadically. For example, it now uses a new window to pop up image details; that's very '90s; something like Lightbox, using a Javascript layer, would be far more appropriate.
There are several I'm looking at for inspiration: popSlides for great popups and transitions (probably inspired by the older Lightbox), but it has no thumbnail navigation; popeye 2.0 due to the neat trick of growing from thumbnail to detail view in place, although horrible choice of placement of controls (mid-image) and darkening the image; GalleryView is a very basic filmstrip gallery, as is jMyCarousel; Smooth Div Scroll for the, well, smooth scroll, autoscroll, and nice edge controls via mouse-over (and speedup if you press the button); ImageFlow has a neat effect of showing central items larger and having others recede, like the Mac dock, but has horrible navigation; and AD Gallery is quite smooth and adds good-looking captions but shows the larger image inline, where I want a popup. These are all jQuery-based (some use jQuery UI); I settled on jQuery, although I also use Prototype/Scriptaculous.
A synthesis of the best features of all of these (for my purposes) will be developed, and I'll embedded it in these entries as appropriate rather than using the present static thumbnail system. It should also make it faster for me to put up entries with photos, since I won't need to worry about layout any more: I'll automate it, and just pick the photos I want to use and let my new engine handle the presentation.
Books finished: Heidegger and a Hippo Walk Through Those Pearly Gates, Basic Economics.
