Standards: so many to choose from!

It's an old joke that gets trotted out at most standards meetings but the truth is that most bits of technology are the result of hundreds, if not thousands of supporting components and systems.  Just image how many technical standards must apply to something like the average family car once you've taken into consideration all the components.

The world of software is no less complex.  I just had a look at the UK government's survey on use of open standards: the number of standards is not only bewildering but when I got to the section on education I realized that it is clearly still only the tip of the iceberg.  And I didn't spot HR-XML, SIF or PESC to name just a few.

Those with an interest in UK public sector procurement might want to hop along to the survey website

My First Steps into the Iron Age

When PyAssess was originally being developed we did some experiments on getting it running in Jython.  Jython is an alternative implementation of the Python interpreter which runs inside a Java virtual machine.  Unfortunately, we'd relied fairly heavily on being able to distinguish regular ASCII strings and Unicode strings and this was not supported in Jython at the time.  I'm sure it has moved on since then but I haven't had a second go - and anyway, for Python 3 I'll need to sort the string/unicode issue out anyway.

C# programmers work in a similar environment to Java.  (As an aside, the sheer cost to the industry of Microsoft and Sun's failure to reach an agreement in those early days must be staggering.)  Not surprisingly, there is a C# equivalent to Jython, the project is called IronPython and I feel that it is about where Jython was when I was involved in my previous PyAssess experiments around 2003.

With my expectations set realistically I set about taking the first steps towards getting my latest python code running in the .Net environment using IronPython.

Installing IronPython and the associated toolset for Visual Studio 2010 went well and there was a useful walkthrough document to help me get started.  However, much of the documentation seems aimed at introducing experienced Windows developers to Python whereas I could have really done with something the other way around.  My first problem was that I'd installed Visual Studio 2010 with some type of Product Management profile and step 1 of the walkthrough involved selecting a menu option I didn't even have!  I couldn't figure out how to automatically reconfigure the menus in Visual Studio (even rerunning the installer) so had to go hunting for the "New Project..." menu item and add it to the File menu manually.  Still, when in Rome...

My simple "Hello World!" script went without a hitch but I ran into the following issue almost immediately: http://ironpython.codeplex.com/workitem/29077  - I ended up writing the following code which has to be used as a prefix to the first loaded python module in the project (and assumes you've installed your IronPython in the default location).

try:
    import string
except ImportError:
    import sys
    IRONPYTHON_PATH_FIX=['.', 'C:\\Windows\\system32', 
        'C:\\Program Files\\IronPython 2.7\\Lib',
        'C:\\Program Files\\IronPython 2.7\\DLLs',
        'C:\\Program Files\\IronPython 2.7',
        'C:\\Program Files\\IronPython 2.7\\lib\\site-packages']
    sys.path=sys.path+IRONPYTHON_PATH_FIX
    import string

As usual, the command window in Windows seems to dissappear before you've had a chance to read the output of your program but I did eventually get the following script working (with the above header of course):

import string, time
print string.join(['Hello','World!'],' ')
time.sleep(10)

In the traditional spirit of starting to run as soon as I'd taught myself to walk I checked out the latest python package code (pyslet) from the QTI migration project and installed it.  I was intrigued that IronPython has byte-compiling disabled but this doesn't seem to prevent the install from completing.

My next task was to check out the unittests and run them against the installed module.  At this point I tripped over my laces and fell flat in the mud: setuptools is not supported on IronPython and, therefore, the pkg_resoures module I use to check dependencies in the unittests is not available.

It is probably too much to expect a complex module like setuptools to work at this stage, I feel somewhat chastened by the realization that it isn't part of the main python distribution yet anyway!  This two-year old blog post suggests that problems getting zlib working are holding it back but the good news is that zlib is reported to be fixed in the latest release of IronPython (2.7) -- this was only released a couple of weeks ago and is one of the reasons why I'm looking at this environment now.

So although progress halted, I think I can work around the lack of pkg_resources.  I now plan to add exception handling to prevent it aborting the tests and have another go, at which point I'll post an update on progress to this blog.