Python Programming, news on the Voidspace Python Projects and all things techie.

.NET Rocks Podcast: Michael Foord Talks IronPython

I've recorded a podcast with the .NET Rocks guys on IronPython. We discuss dynamic languages on the .NET framework (I'm even nice about Ruby!), Python, IronPython and of course Resolver One and IronPython in Action:

Michael Foord Talks IronPython Michael Foord works full time with IronPython for Resolver Systems; creating a highly programmable spreadsheet called Resolver One. He has been using IronPython since about version 0.7.

The podcast is 53 minutes long and it was great fun chatting with Richard and Carl. Towards the end of the podcast there is a discount code for ordering IronPython in Action, so well worth listening to all the way to the end.

Apparently the .NET Rocks podcast has around 300 000 (!) regular listeners, so it was great to be able to promote Python and the book to the .NET community.

Introduction to ConfigObj Article

In May 2008 the Python Magazine published my Introduction to ConfigObj article. ConfigObj is an easy to use but powerful configuration file reader library.

This article is a great introduction to ConfigObj, but is a particularly useful reference on the config file validation features. The documentation is complete, which doesn't necessarily make it a good place to start, so this is probably the best reference for getting started with validation. The article also covers features like Unicode support and unrepr mode.

Many thanks to the Python Magazine for allowing me to reproduce the article in full.

In the process of putting this online I've managed to fix a couple of the inevitable (but irritating) typos that were in the original. If you spot any more typos or errors then please let me know.

Oh - and a new release of ConfigObj is coming soon. It mainly includes improvements to validation (including support for validating multiline values and removal of restrictions on '__many__' validation).

Multi-monitors and the Hazro 30" Monitor

My colleague Kamil Dworakowski has written a blog entry on using multiple monitors, showing off his desktop setup (the deathstar control centre) at Resolver Systems: Quad Head

Traders have long known about the value of using multiple monitors. The reason it is so good for programming is that the activity requires to keep millions of things in the head at once -- names of variables, functions, classes, third party APIs. You can keep limited amount of things in your head, depending on various factors affecting your concentration like amount of sleep the previous night. You will have to page fault to the rest. And when page faulting requires switching between windows it adds friction. Energy that could have been used on solving problems is wasted. Allocating windows across monitor is crucial. You want to have the information you will need most often readily available. What you don't want is to have two windows to which you need simultaneous access being on the same monitor. Even with four monitors, you will find that you have more than one window on the same monitor. My average is about 2-3 windows per monitor and 2-3 virtual desktops (don't worry I don't use splits ;). For past month I had one virtual desktop for lunch time, one for spiking an interactive console for Resolver One, and one for main development. Vista is not really well prepared for 4 monitors; windows appear on different monitors at random. It is not unusual that an application on monitor 4 will popup a dialog on monitor 1. Without some third party tools it would be a chore to manage it all. I use winsplit for moving windows around, vdm for virtual desktops and ultramon for extending the taskbar.

I quite agree that having several monitors really improves development experience; and whilst I hate to play the "mine is bigger than yours" game, I'm currently running five monitors:

My main monitor is now a 30" Hazro monitor. The others are a 32" LCD TV, 22" widescreen and two 24" monitors. (I watch movies on the top monitor - fed from my computer - and the middle monitor runs a Vista VM.) The 30" monitor is a recent addition. I've long wanted one - with a resolution of 2500x1600 is large enough to have two applications side by side in the same monitor at the same size as they would be on a standard 20" monitor. 24" monitors are typically 1900x1200 pixels - too wide for a single application and not wide enough for two side by side at a decent width.

Note These monitors are driven by an Apple Mac Pro with three graphics cards - each supporting two monitors. The cards are 2x ATI Radeon HD 2600 XT and 1x NVIDIA GeForce 8800 GT. The LCD TV is a 1080P monitor, which means it has a 1920x1080 pixel resolution when plugged into the computer via HDMI. I don't have a blueray drive, but watch a lot of movies in 720P format. The improvement over standard definition compressed movie files is astonishing. A 720P movie encoded using a modern codec (like H.264) is typically 3-4gigs. A 1080P movie is typically 24gigs. I've only downloaded one and couldn't find a player for the Mac that could work with the video container format it used (although PowerDVD on Windows handles it fine apparently). The best resource on video codecs (etc) that I've seen is a series of articles by Mark Pilgrim, A gentle introduction to video encoding: Part 1: container formats

Part 2: lossy video codecs

Part 3: lossy audio codecs

Part 4: captioning

Part 5: constraints For the curious I use a Kinesis Advantage Keyboard which is unjustifiably expensive but really helps with my RSI. I also use the Kensington Expert Mouse which isn't a mouse at all but a trackball (and the scroll ring is very cool). It is much more sensitive than a standard mouse, but I haven't tried it for gaming yet. Both the mouse and the keyboard are wired which is annoying. I'll do a separate blog entry on these sometime. I have a separate number keypad as there isn't one on the Kinesis (well you can switch it into a separate mode which I should probably try). Once you get used to a numberpad you can't do without them - they speed up number entry enormously. (I worked in a Builders Merchant for many years.)

I've resisted the lure of thirty inches for a long time because they are still hugely more expensive than 24" monitors. The market leaders for 30" monitors are Dell and Apple, and they cost around a thousand pounds or so. A good twenty four inch monitor can be had for around two hundred pounds. I recently found a cheaper alternative, the 30" Hazro Monitor. Allegedly they take the same panels used in the more expensive Dell monitors and use cheaper housing with less markup. If you read the reviews (google for them - there are quite a few), they are almost universally positive. I found one from Overclockers.co.uk for six hundred and seventy pounds (including VAT and shipping) - about a third cheaper than any other I had found.

At first I was very nervous about ordering. I hate dead pixels on monitors and have been very lucky on the monitors I have bought so far. Hazro's dead pixel policy even allows for 5x5 clumps of dead pixels. Fortunately I got very good advice on Overclockers own forum:

If you still have a dead pixel problem, can't bring it back to life and can't RMA it under warranty then you can sometimes return it to the stockist if you purchased it online. If you bought online you can take advantage of the "Distance Selling Act" which entitles you to return any item within 7 days as you were not present at the time of purchase. If you are not happy with your TFT you can return it at your cost of postage and often claim a refund or exchange. Legally, if the stocker accepts the TFT back as a return governed by the Distance Selling Act, then they are NOT allowed to charge you a restocking fee as covered in the Government Regulations (page 11 in particular). This selling act is not widely known by retailers, but does exist if you really need to use it. You should only have to pay for postage to send it back to them.

(Obviously the distance selling act only applies in the UK.) On that basis I was happy to order it and would have returned it if there were any dead pixels. Fortunately there were none.

This is what it looks like:

It's not a perfect monitor, but overall I'm very pleased with it. Here's the good and the bad.

The good:

Lovely image quality

No dead pixels

Really a lovely monitor

Comes with the dual-link DVI adaptor lead it requires (although a bit short)

Does have vertical tilt on the stand (not all cheap monitors I've bought have this)

The bad:

It runs quite hot (not really an issue, but even so...)

Vertical tilt only - no horizontal movement on the stand

Can't remove the stand so can't wall mount it

The touch power button is inconveniently recessed at the bottom of the monitor and not sensitive enough - I usually have to swipe it several times

The configuration options are basic - but the default setup was absolutely fine for me on a Mac Pro.

Python, Wing on Quartz, and ConfigObj in Textmate

A bunch of stuff, almost all of it interesting to someone (usually me).

Someone likes ConfigObj, but wanted highlighting for the ConfigObj format ini files in Textmate - so he created a Textmate bundle. I like what he says about ConfigObj:

We use ConfigObj configuration files pretty extensively at WebMynd; it would be nice to use the ConfigParser module available in Pythonâ€™s standard library, but the extra features ConfigObj has, such as lists, multi-line strings and nested sections, make it hard to say no to the richer library...

Knowing even approximately how many Python programmers there are is very difficult, in fact even defining a Python programmer is difficult. Is someone who writes a simple Trac plugin or shell script a Python programmer? Even counting downloads will be a wild underestimate. Python is included in most Linux distributions (and is preinstalled on the Mac), and even Linux users who upgrade are likely to do it through their OS's package management rather than from Python.org. However, most Python programmers on Windows will use the standard installers. In January the Python 2.6.1 installer for Windows was downloaded 348 761 times! In that month Python installers for Windows were downloaded more than a million times!

My favourite Python IDE, which I use on both Windows and the Mac, is Wing. The UI uses GTK, which in turn uses X11 on the Mac. On the Mac X11 comes with the OS, but is also developed by Apple as an external project called XQuartz, and as the official updates are slow it is usually better to track XQuartz. Michael Burton recently posted to the Wing mailing list about some improvements from upgrading to the latest version of XQuartz:

I just noticed that XQuartz has updated apple's X11 server to 2.3.2.1 (the one apple ships with Leopard is 2.3.1 I believe) . It seems to fix a number of weird behaviors I've noticed with Wing, such as: tooltips appear when wing is in background

weird issues with dialogs popping up at inopportune times when using the external tools layout

problems with copy/paste when using a clipboard manager such as Jumpcut

fix occasional "stuck keys" when switching between apps All in all, it seems like a vast improvement. However, there's one change that seems to have dramatically changed the way that Wing displays. From the release notes: "Default dpi reported is now 96 instead of 75" http://xquartz.macosforge.org/trac/wiki/X112.3.2.1 When you first load wing in 2.3.2.1 the fonts will all appear HUGE. To switch back, run the following in Terminal (from the FAQ): defaults write org.x.X11 dpi -int 75 http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ

PyPy and Psyco

Psyco is the specialising compiler - basically a JIT - for Python 2.X. It has been in maintenance only mode for a long time, not even optimising generators which were introduced to the language in Python 2.2. Maintaining and extending Psyco is so painful that it was part of the motivation for Armin Rigo joining the PyPy Project. Some people are still confused about PyPy; about what it is and what it hopes to achieve.

PyPy is really two projects:

An interpreter compiler toolchain allowing you to write interpreters in RPython (a static subset of Python) and have cross-platform interpreters compiled standalone, for the JVM, for .NET (etc)

An implementation of Python in RPython

(There are also subprojects like Prolog and Smalltalk front-ends written in RPython).

These two projects allow for many things.

Maintaining Python in Python is much easier than maintaining it in C

From a single codebase you can generate Python interpreters that run on the JVM, .NET and standalone - rather than having multiple slightly incompatible implementations

Part of the compiler toolchain includes an experimental tracing JIT generator (now in its fifth incarnation and starting to work really well) - the goal is for a JITed PyPy to run much faster than CPython

It is much easier to experiment with fundamental language features - like removing the GIL, better garbage collection, integrating stackless and so on

So there are really a lot of reasons for PyPy to be exciting, and it is finally starting to live up to all its promises.

Meanwhile, Psyco isn't completely out of the game. In fact there was recently some news:

This is not an official announcement of Psyco V2, yet. But everybody who is interested should check out http://codespeak.net:/svn/psyco/v2 and do some testing. The major improvement besides lots of builtins is the new generator support, which is disabled by default, due to an internal error in Psyco. To use and test generators, create preferences.py, following the instructions in setup.py. This software is considered asan alpha release. The final version should be expected before end of February. regards Christian Tismer

The downside is that there is still never likely to be a version of Psyco that supports 64bit or Python 3 (in fact Christian Tismer is more positive than I thought on this subject - see his comment on this reddit thread).

And as for the future of PyPy, well, good news everyone:

we're now able to translate a highly-experimental Python interpreter that contains JIT. It mostly crashes immediately, mostly due to some unsupported operations in the assembler backend, but for a carefully crafted program, we're able to get massive speedups. For something as complex as: i = 0

while i < 10000000 :

i = i + 1 our JIT is about 20x faster than CPython. That's still about 3x slower than Psyco, but looking at assembler code it's obvious that we can speed it up a lot. These are very good news, since we don't encode python semantics at all in the JIT. The JIT is automatically generated from the Python interpreter source code. This means we should be able to expand it to handle more complex python programs relatively quickly (interested assembler experts needed!).

Archives