Python

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.

The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot.

The actual code to the demo application is rather brief. Continue reading "PyGTK/glade object reuse"

A little utility that has been collecting dust on my harddrive over the past two years is an enhanced version of a PyGTK exception handling module that was originally posted to the PyGTK mailing list by Gustavo Carneiro. I've now uploaded it to the sysfs download area; it is essentially unlicensed, considered public domain by Gustavo according to his email message.

Besides fixing a API incompatibility with recent PyGTK releases, there are two main differences with the original functionality.
First, I've modified the traceback formatting to include two lines of context to each line in the traceback, one before and one after the called line. Also included is a printout of the identifiers referenced in the traceback lines — variables, usually. On my personal wishlist was also syntax coloring in the debug window, but this was both non-trivial to implement, and it would likely add considerably to the complexity of the error handler, thus increasing the chances that the error handler itself would fail.
The other main functionality change is possibility to email feedback to a predefined address — mainly meant for deployment and debugging of company-internal applications. To enable this feature, two identifiers feedback and smtphost must be set on the module. This can be either by modifying the code, or, better, by adding them after module import:

import gtkexcepthook
gtkexcepthook.feedback = 'valid@email.address.here'
gtkexcepthook.smtphost = 'relay.smtp.hostname'

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.

Since no such beast seemed to exist yet, I have hacked up a wrapper to turn an existing python CGI script into a WSGI application. The result is available from the sysfs download area as cgi2wsgi.py.

The wrapper requires you to rename the original CGI script to somecgi.py (pick a name), make it available in the python path, and set the name you gave the script in the wrapper wrapcgi method. This is due to the way it works: it mangles the environment and standard output, and then tries to import the CGI as a python module. Any output is gathered, split into headers and data and then returned to the WSGI server. An alternative approach could have been to create a full-fledged CGI environment and run the script by forking or another equivalent method, with the added bonus that this should work even to turn non-python CGI scripts into WSGI applications; but this looks like a lot more work than the import approach I used (which was tricky enough in certain details already).

The wrapper is not complete as it stands: there are a bunch of variables which are usually available to CGI scripts but aren't when the CGI is loaded by the wrapper. Also if your script uses globals and does not reset them to a sane state before use data may linger in between subsequent invocations. However, I have successfully run a few applications through it so it should provide a reasonably good base to start from. And it did show a few bugs which were not triggered in a standard CGI environment.
The best way to figure out weak spots in your CGI script is probably by running the wrapper in a WSGI server which is not run itself through CGI, to avoid the WSGI server environment leaking through to the application. If run standalone, the wrapper tries to use the OwlFish.com WSGIUtils to this purpose.

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.