return to OCLUG Web Site
A Django site.
January 23, 2012

Ian Ward
excess - News
» Urwid at Python Malaysia

I'll be giving a introductory-level presentation on Urwid at the Python Malaysia February Meetup in two weeks. I'm covering the basics with a short presentation and there should be plenty of time for questions or digging in deeper on any aspect.

[Update 2012-02-04]: Slides now available

[Update 2012-02-06 added some photos]

December 19, 2011

Ian Ward
excess - News
» Unfortunate Python

.red {color:red}

Python is a wonderful language, but some parts should really have bright WARNING signs all over them. There are features that just can't be used safely and others are that are useful but people tend to use in the wrong ways.

This is a rough transcript of the talk I gave at my local Python group on November 15, with some of the audience feed back mixed in. Most of this came from hanging around the Python IRC channel, something I highly recommend.

[update 2011-12-19: improved "array" critique, add "python -i" suggestion to "reload" critique, add html targets to sections]

[update 2011-12-20: include additional links from agentultra and ffrinch]

[update 2012-01-06: added hasattr and find]

[update 2012-04-09: some links and syntax highlighting]

November 29, 2011

Ian Ward
excess - News
» Urwid 1.0.1 and Released

Urwid maintenance releases 1.0.1 and are now available. This may be the last 0.9.9 release, users are strongly encouraged to upgrade.

November 25, 2011

Brenda Butler
» excellent twisted documentation

I found a site where there is some not-just-good, but right-out excellent twisted documentation.

September 23, 2011

Ian Ward
excess - News
» Urwid 1.0.0 Released

This is a major feature release for Urwid.

Happy 1.0 Urwid! It's been a great nearly-seven years since our first release. Huge thanks to everyone that's contributed code, docs, bug reports and help on the mailing list and IRC.

September 19, 2011

Ian Ward
excess - News
» Widgets, Form Fields and Model Fields Explained

In any web application user data must be translated from HTML form data to native types and database types, and back again. Django web applcations are no different.

The "right way" to handle custom types is to extend Django's widgets, form fields and model fields. However, understanding exactly how these types perform each step of the conversion can be confusing. This post will attempt to explain how the data is converted at each stage and offer some advice about creating custom widgets, form fields and model fields.

This article is based on Django 1.3 and assumes the reader has experience creating and using Django forms, models and validation.

September 6, 2011

Ian Ward
excess - News
» New Arevco Site Launched

The third iteration the Arevco Lighting web site is now up.

The old site was simple HTML and images generated from a script, which I quite liked but wasn't the easiest thing for other people to update. The new site has been professionally skinned and is now running a Django CMS with some custom index code for product pages. I used the following:

I've used Gerbi now for a few public web sites. It's a well designed and usable CMS that is quite easy to extend. It also has good multilingual support that will make translating content as easy as editing the pages.

August 30, 2011

Michael P. Soulier
But I Digress
» Some languages make you work too hard

Disclaimer: Python is my language of choice for programming, but I have a long Perl history as well.

Coming from Perl, when I find that I must do something simple like taking a string, delimited by pipes, and split it into a hash/dict/associative array/whatever.

mystring = foo|1|bar|2

So I want to take that, and split it into name/value pairs in a mapped data structure. This is trivial in Perl

%map = split /\|/, $mystring;

Now, in my language of choice, this should be simple too, right? Umm, not so much.

map = dict(zip(mystring.split('|')[:-1:2], mystring.split('|')[1::2]))

Geez, if I wanted to type that much, I’d use Java.

To be fair, there are tasks in Python that are trivial and are much harder in Perl, but this is just one of those cases that I find could be made much simpler. Why not just allow dict() to take a list?

Ruby seems to have learned that lesson, even if the syntax is a tad ugly.

msoulier@anton:~$ irb
irb(main):001:0> mystring = "foo|1|bar|2"
=> "foo|1|bar|2"
irb(main):002:0> Hash[*mystring.split('|')]
=> {"foo"=>"1", "bar"=>"2"}

Not a bad medium between the two really. I like Ruby’s design, too bad the docs suck horribly.

July 13, 2011

Ian Ward
excess - News
» Urwid Released

This is a maintenance release that fixes a number of bugs that have been found in

June 14, 2011

Ian Ward
excess - News
» Python 3 Argument Sketch Slides

Here are the slides from my Python talk at OLS this afternoon.

June 9, 2011

Brenda Butler
» unicodedata to the rescue

I have a database full of strings where the accented characters have been replaced by their non-accented equivalents, and a spreadsheet full of strings with accents in them. I’m supposed to look up the info in the database given the info in the spreadsheet.

I found this great stackoverflow post that helped me out:

title = u"some string with accented characters in it like b\xe9cancour"
import unicodedata
unicodedata.normalize('NFKD', title).encode('ascii', 'ignore')
'some string with accented characters in it like becancour'

Normalize with ‘NFKD’ will decompose each character in the string into its composing characters. For example, if there was an e with acute accent, it separates it into an e and an acute accent. The K part of NFKD ensures the ‘e’ is the simplest possible e (presumably if there is an ‘e’ in ASCII, it will prefer that one). Then the encode ('ascii', 'ignore') will drop all the non-ASCII characters, which by now are just the accents which have been separated from the rest of the letter.

Awesome. And it works in python 2.5.

May 25, 2011

Ian Ward
excess - News
» Python on Android, Django Unit Testing at OPAG

Ottawa Python Authors Group meeting tomorrow Thursday May 26 at 8p.m. Best of all it's not me talking this time!

Hope you can make it out.

May 20, 2011

Ian Ward
excess - News
» Python 2 and 3 Slides

Catching up on some more old business: here are the slides from the Python 2 and Python 3 talk I gave at last month's OCLUG meeting.

I am also preparing some Python tutorials for the upcoming 2011 Linux Symposium in Ottawa June 13-15. Hope you can make it.

April 4, 2011

Ian Ward
excess - News
» Python Talk at OCLUG on Tuesday

I will be giving a talk on Python 2 and Python 3 at the Ottawa Canada Linux Users Group meeting on Tuesday. Hope to see you there.

March 23, 2011

Ian Ward
excess - News
» PyCon 2011 Videos

Here are some of my favourite videos from this PyCon this year:

March 22, 2011

Ian Ward
excess - News
» Python Data Structures at the Pub Wednesday

The Ottawa Python Authors Group is gathering at the Georgetown pub on Wednesday March 23. The theme of this meeting is Python Data Structures and String Processing. It's a great topic for beginners and experienced python users alike. Hope to see you there.

February 17, 2011

Ian Ward
excess - News
» Moving to Python 3

My article on supporting Python 2 and Python 3 from the same code base is now freely available on The article is based on my recent work on Urwid's Python 3 support. I owe thanks to the people that started and contributed the compatibility work on github and bitbucket. I'm looking forward to a release with Python 3 support very soon.

I also gave a talk at last night's OPAG about these changes. Thank you to all those that came out, we should have these meetings more regularly. Maybe back at the pub next time?

January 11, 2011

Ian Ward
excess - News
» OPAG Pub Meeting Tuesday

The Ottawa Python Authors Group is gathering at the Georgetown pub tomorrow. The meeting is open and unstructured this time. I'll be there presenting a bit of my recent work with Python 3 and hg-git.

December 13, 2010

Ian Ward
excess - News
» Django Hides (some) Widget Exceptions

If you write any custom Django widgets or admin list_display callable functions you have probably run into this: Everything looks ok, except the place where your widget should be is just blank. Nothing. No traceback or any clue as to what went wrong.

It seems that Django suppresses all the exceptions sent by widgets rendering except for AssertionError and TypeError. Debugging under those conditions is tricky, so I wrote a function decorator to help. Just import this and put @assert_on_exception before your render method or admin list_display callable function:

def assert_on_exception(fn):
    import sys
    def wrap(*args, **kwargs):
            return fn(*args, **kwargs)
        except (AssertionError, TypeError):
            assert 0, sys.exc_info()[0].__name__ + ": " + str(sys.exc_info()[1])
    wrap.__name__ = fn.__name__
    wrap.__doc__ = fn.__doc__
    wrap.__module__ = fn.__module__
    return wrap

November 11, 2010

Michael P. Soulier
But I Digress
» DBUS, an interface only Java programmers could love

I decided to move away from Gnome on my netbook desktop, as recent Ubuntu updates caused more problems than they solved, and now I’m back to running my beloved Fluxbox. Of course, doing so means that I lose some conveniences in the Gnome desktop.

For example, when I close my laptop lid, the netbook no longer suspends. I’ve assigned a hotkey to this but maybe I want it to be automatic. This got me thinking about how to make this work. Well, it’s done through DBUS of course.

DBUS has become ubiquitous on Linux systems, providing a sub/pub model for events in Linux, which is a good thing given that the POSIX spec provides very little to make this kind of thing happen. I’m more of a fan of files, directories and symlinks myself, but I can understand why some programmers would want something a little more sophisticated, even if I don’t.

Being a Python hacker I want to use the python dbus module, so I install python-dbus and I’m off and running, albiet with little to no documentation. Google allows me to find enough clues that I’m led to qdbus to query the system bus, and I find org.freedesktop.DeviceKit.Power, which exposes a LidIsClosed property and a Changed event.

So, looking at some examples I manage to get this far…


import dbus, gobject
from dbus.mainloop.glib import DBusGMainLoop

power_iface = None

def main():
    global power_iface


    bus = dbus.SystemBus()

    proxy = bus.get_object('org.freedesktop.DeviceKit.Power',

if __name__ == '__main__':

As the object that I want is not available in my process, I must instantiate a proxy to it via dbus. To get this proxy I call get_object on the bus object, passing the name of the object and then, somewhat redundantly, a path that seems to represent a namespace of properties, signals and methods.

Ok, so now that I have the object I can just check the LidIsClosed property and register for that signal, right? Wrong. For no apparently reason now that I have the object, to call methods on it I need an interface object, representing one of the interfaces that this object implements. That’s just so…Java, that it rubs me the wrong way, but I forge on.

I want the interface that allows me to query properties, and apparently all objects in DBUS implement some common interfaces, because this is how I get the interface I need:

power_iface = dbus.Interface(proxy, 'org.freedesktop.DBus.Properties')

My take on this is that I am asking for the standard freedesktop DBus Properties interface on the DeviceKit.Power object, so that I can query its properties. Overly complex when simple would do? Absolutely. Does it work? Sure, but why would anyone choose to work this hard deliberately? Oh, Java programmers. I forgot.

Now I want to register a listener for any changes from the Power object, which includes the lid being closed. You do this like so, via a callback:


Why you don’t use the existing proxy object to DeviceKit.Power is beyond me. Maybe you can and I simply don’t understand the API. I would have envisioned something like…


…but that’s me. I guess some people really like typing.

Now, we finish this off by writing our handler…

def handle_lidclose(*args):
    closed = power_iface.Get('org.freedesktop.DBus.Properties', 'LidIsClosed')
    if closed:
        print "lid is closed"
        print "lid is open"

…and starting our main loop via…

    loop = gobject.MainLoop()

All that’s left is to write the call in my handler to suspend the laptop if
the lid is closed, but honestly, my fingers are tired. I particularly love the
way that I need to pass the full interface specification in the Get() method
even though I’m calling it via…an interface object. Can you say redundant?
No wonder Java programmers need IDEs.

I hope this situation improves. Unix used to stand for power through simplicity. Less code is less to break, and simple APIs leave developers free to worry more about bugs in their code than try to comprehend a needlessly complex API. Maybe I just don’t get it. These are first impressions, afterall, so perhaps I’m being overly judgemental. Perhaps there’s beauty and simplicity and elegance to be found in this overly wordy API requiring redundant information.

For now though, I just don’t see it.