, simplejson and json modules

When dealing with JSON objects in Python, we have the excellent simplejson module to convert a JSON object into Python object. But, in Python 2.6 (and 3.0), we have the json. While loading it’s as simple as

    # Python 2.6/3.0 JSON parser
    import json
except ImportError:
    # Fallback to SimpleJSON
    import simplejson as json

And you would just need to use json.dump(), that leaves the problem of pointing if the application requires simplejson or not in the The solution is use sys.version_info comparing versions with distutils.version.StrictVersion:

from distutils.version import StrictVersion

import sys
version_number = '.'.join([str(a) for a in sys.version_info[:3]])

if StrictVersion(version_number) < StrictVersion('2.6'):
    params['requires'] = ['simplejson']


  • First of all, params is a dictionary of parameters passed to setup (as setup(**params), as Python supports passing a dictionary as a list of parameters as a function.) Another probable solution would be use a requires variable and set it to None in case the version is superior than 2.6.
  • The version_number uses just the first three elements in sys.version_info 'cause it also contains other information like "final" or "rc" and the release info (e.g., Python 2.5rc1 would have a sys.version_info of (2, 5, 0, 'rc', 1))
  • StrictVersion provides proper comparison between versions, so you don't have to worry about Major, Minor and Release versions or even have to write three cases in an if.

Is Mitter dead?

As some may have noticed already, there haven’t been many releases of Mitter lately. But it doesn’t mean Mitter development is dead. I’ve been working on some things lately:

  • Multiple network support:
    One thing I’m trying to make now is support for multiple networks, so you could update your status on Twitter,, Facebook, Jaiku and whatever from just one client. The weird thing is that, this time, I decided to actually write the design down and then start working on it, to avoid creating a mess of code but, in the end, every single step I did into code proved that I forgot something (yay for Python and fast prototyping!) I still see some rough edges everywhere, but I think after a week working on it, I got a huge step forward.

  • The damn network thread:
    Not something I’ve been actively working on, but I think about it from time to time. The main reason it bothers me is the problems with the PyGTK main loop on Windows and the ugly ugly hack for the console interfaces (tty and cmd.) At first I thought about converting the network interface into a file-like object, so it would be just a matter of “read()” the data, but that proved to be a problem with the idea of multiple networks. Right now, I want to try to split the HTTPThread into a single object and the interfaces would be able to mix it with the Network/Twitter objects. So, only interfaces that need threads will have a HTTPThread-like object to use; interfaces that don’t have that problem will use the Network/Twitter object directly.

  • Tk(inter) interface:
    Also with the problem with PyGTK on Windows, I decided to play a little bit with Tkinter. Now, everyone knows that it looks pretty bad on X11 interfaces, but on Macs and specially Windows, it tries to mimic the OS look (even more on Windows, where it translates Tk commands directly into Windows.) So far, it looks alright and I even have a working prototype (not plugged into the Mitter object yet, though.) Here are some screenshots:

    The first thing you’d probably notice is that it doesn’t look like the PyGTK interface. That’s because Tk supports only one line for items on listboxes, so I had to make a space for the whole tweet or you’d get just a glimpse of the text. I’m not looking into links and other stuff yet, but maybe in the future.