In a previous life, I wrote a proprietary application for a certain
wire die manufacturer. Having just discovered
the joys of Python, and wanting to deploy in a cross-platform
environment, I wrote it using wxPython and
suffered dearly for the choice. Maybe suffered isn’t the right word:
wxPython was clearly the only toolkit for the job (for a variety of
reasons), but it didn’t do everything, and as such writing the
additional code and widgets was more painful than Python should ever be.
Fast forward 6 months. Today I started working on a new application
which has as a requirement cross-platform deployment on Mac OS X and
Win32. Linux would be nice, in my opinion, but it’s not on the short
list of requirements. Once again, wxPython is the only toolkit for the
job, and I must say I’m very impressed so far. This afternoon I
downloaded the newest release,
2.5.1, from SourceForge and
expected to begin the process of reaquainting myself with C internals
and obscure, “non-Pythonic” names. Instead, in under two hours, I was
able to get a basic GUI put together and have preliminary event binding
working. Rereading the last sentence, it doesn’t sound like much of an
accomplishment. But when I look at how clean the code is, and how much
easier it was compared to before, I’m definitly impressed.
The changes that have taken place in the toolkit are too numerous to
mention here. The net effect, however is that developing an
application’s GUI no longer feels like it gets in the way of developing
the application’s core functionality. Bob
Ippolito didn’t seem too impressed with
wxPython at PyCon, but after using it, I must dissent: if you want
cross-platform development, Python and wxPython are the way to go.
As I mentioned
I’ve been hacking on an update of ccValidator. Well, more than an
update: a complete refactoring, really. The small item that prompted
this was the ability to validate pages whose RDF is specified in a
<link> tag instead of an HTML comment. I haven’t even
addressed that yet :). But I will; real soon now.
So what’s changed? A lot. First, I’m now using the
Quixote framework. This
has been a generally positive move: the output.py module that
existed previously has been removed, and the HTML generation is a lot
less “magic”. I’m also using the new rdfExtract classes (which have,
incidently, been rolled in with ccRdf in CVS). Finally, the
reorganization around Quixote has allowed the validator to become much
more modularized: instead of a bunch of Python that executes as a CGI,
there is now a CGI driver and a Python package which can be anywhere in
the Python path. Quixote also allows the validator to run under
mod_python, FCGI and as a standalone process.
The plan is to have a test instance up by the end of the week, and a
long period of coexistance with the existing stable instance.
Eventually, though, the new validator will replace the existing one. I
haven’t cut a release yet, but the code is available in
CVS (the module is
I’ve just posted the first draft of
rdfExtract, and am actively looking for
comments and suggestions. As the linked page describes, rdfExtract is a
pluggable RDF extraction class. What does that mean, exactly? Well, it
means that if you want to handle the extraction in some different way
(say, by lowercasing it or something), you just write a function that
takes a string (the text to extract from), and returns a list of strings
(the RDF blocks).
I’m developing this for use in the new version of
ccValidator. Instead of tacking support for
LINK’d RDF onto the existing code for extraction, this will allow me to
write a simple function which scans the incoming HTML for the
appropriate <LINK> tag and retrieve the URL specified.
It’s been suggested that having rdfExtract return Python objects instead
of strings would be useful (sort of like a generic
ccRdf). I agree, but don’t have time to do it now.
Any other suggestion, comments, criticisms? Let me know.