Today we’re going to cover something which isn’t in the standard library, but is nonetheless very useful. The module is configobj which is used for reading from and writing to INI style configuration files files. A simple INI file is shown below:

item1 = value
item2 = value2
 
[ section1 ]
item1 = value
 
[[ subsection ]]
item1 = value

In the above we can see the simple use of items, values sections and subsection. Subsections can be nested down as far a you want, but I don’t think most applications will need many more than two or three levels.

Installation

As this module isn’t in the standard library, we need to install it. On most Linux distros it should be in the package repositories, for example on Fedora 14:

$ sudo yum install python-configobj

Windows and Mac users can install from PyPi by following the instructions on the homepage.

Basic Usage

Reading from a configuration file with configobj couldn’t really be any simpler:

import configobj
config = configob.ConfigObj(filename)
myoption = config['item1']
mysectionoption = config['section1']['item1']
mysubsectionoption = config['section1']['subsection']['item1']

Basically, all you need to do is open a ConfigObj object by passing it a filename, then you just read from it as if its a dictionary object. Sections and subsections appear as nested dictionaries. Writing to the file is just as simple:

import configobj
config = configob.ConfigObj(filename)
config['newoption'] = 'new stuff'
config.write()

No surprises here, you just write to it as if it were a dictionary. All you have to do it call the write() method when you’ve finished, in order to sync everything to disk.

That’s pretty much it for basic usage. There is much more you can do with configobj, including advanced stuff like validation of configuration files. Check out the documentation for more info.

>>> import shelve
>>> shelf = shelve.open("myshelf.db", writeback=True)

Here we import the shelve module (its in the standard library, so there’s no installation required). Then we open our persistent object store, supplying the filename that we want to store the objects in and the writeback parameter, which allows mutable objects to be stored more conveniently (otherwise they are only written when an assignment is performed). The writeback parameter also causes data to be cached in memory, which can be quite memory intensive, so you should call shelf.sync() every so on to flush everything to disk.

You can store anything that can be handled by the Python pickle module in a shelf:

>>> shelf['thedict'] = {'one': 1, 'two': 2, 'three': 3}
>>> shelf.sync()

As you can see, using a shelf is just like using a dictionary. The only real limit is that the keys must be strings. You can also read back values from the shelf as with a dictionary:

>>> print(shelf['thedict'])
{'one': 1, 'two': 2, 'three': 3}

That’s just about it, just remember to close the shelf when you’re finished with it:

>>> shelf.close()

If you want to find out more have a look at the official Python docs for shelve and Doug Hellmann’s PyMOTW posting on the subject.

• Installation and Setup
• Site integration
• User interface
• Extensibility (API availability)
• Overall impressions (documentation, community, etc.)

The philosophical argument

As well as the obvious benefit (from a Freedom perspective) of using one less proprietary web service, there is also another reason that I switched away from Google Analytics. Basically, this was privacy. For a while I’ve been using technologies to limit the amount of data which leaks from my browser as I navigate the web, in order to reduce the amount of profiling of my web activities. This isn’t because I have anything to hide. I just don’t like the idea of large companies building up a huge database on me, without my permission. The upshot of this is that I found myself in the slightly hypocritical situation of blocking GA in my own browser, but using it to track others on my site.

The solution was obvious, remove GA from my site. However, I didn’t want to lose the valuable information that it provides me with. Also, I don’t have a problem with site owners collecting data that can help them, just with them sharing it with 3rd parties such as Google, who then build it into their larger profiling efforts. A quick search turned up Piwik which aims to provide a full featured GA replacement that you can run on your own server. Because site owners run their own instances, they remain in charge of their tracking of users, retain ownership of the data and best of all don’t give any data to Google.

With the aim of responsible and unobtrusive tracking in mind I’ve added a page to my site to allow users to Opt-out of the Piwik tracking by means of a cookie. The link is also accessible from the sidebar under the copyright notice. I’m afraid some of the text on that page is pretty difficult to see with my current theme, but I’m working on this. For now just uncheck the check box to opt-out.

Right, on to the main event, the actual review…

1. Installation and Setup

There’s actually not much to say here, which is because installation was ridiculously easy! I just downloaded the zip to my sever (with wget) and unzipped it into my server root directory. This produced a directory called ‘piwik’ and a ‘How to Install Piwik.html’ file, which if you point your browser at it will redirect you to the installation instructions. The rest of the installation was fairly simple, following the instructions I pointed my browser at the ‘/piwik/’ directory of my site and was greeted by the installer. Following this was really easy, you’ll need to create a MySQL database when prompted for the database info, but that’s about as hard as it gets. Towards the end you’ll be prompted to setup your site with Piwik which involves entering a few details about the site, then you’ll be provided with a snippet of JavaScript to add to your site template. Which leads me neatly into the next section…

2. Site Integration

I didn’t copy and paste the JavaScript into my template, instead opting to install the WP-Piwik addon for WordPress. This made the set up easy and also gave me a widget on my WordPress admin dashboard which gives me a nice overview of my site visits. As I already said I was also able to add a widget to the site to enable visitors to opt-out of tracking. This was also simple, just involving a copy and paste of a couple of lines of HTML from one of the settings pages into a WordPress page. Easy!

You can also integrate Piwik widgets with your site, by following the instructions in the documentation, this is a neat feature, especially if you have a custom start page set in your web browser (something which I have yet to get around to making).

I also investigated the campaigns functionality in order to track entries to my site from the RSS feed. This is really simple to use, all you have to do is append the query string ‘?piwik_campaign=NAME’, where NAME is the name of your campaign to the end of a URL, to have it show up under that campaign. I found that I could integrate this with WordPress pretty well by adding the following snippet of code to the functions.php file of my theme:

1
2
3
4
5
6
7

function piwik_track_feed($url)
{
     $url .= "?piwik_campaign=RSS";
     return $url;
}
 
add_filter("the_permalink_rss", "piwik_track_feed");

If you now check the URLs in your RSS feeds, they will all have the query string added and clicks will be attributed to the ‘RSS’ campaign in Piwik.

3. User Interface

The Piwik user interface is really nice. I’ve included some screenshots below, so that you can make up your own mind. It’s pretty similar to the GA user interface, only cleaner and all the AJAX stuff makes it feel really responsive. I also love the real time tracking widget, which is something GA totally lacks. The only bad thing about the UI is the requirement of Flash for the graphs. I hate Flash and it doesn’t have a reliable 64-bit Linux version, which means I only have it installed on my netbook. Oh, and before you ask, I tried it with Gnash and it didn’t work!

4. Extensibility

By extensibility, I was primarily interested in API access. There’s certainly no shortage of this with two APIs listed on the documentation page. One API is for performing tracking, which I didn’t need given my usage of the WordPress plugin. I looked instead at the analytics API, which allows you to access all the data through simple HTTP requests. I was able to write a simple Python script to email me my main statistics once a day, in about an hour (including working out how the Python email and smtplib modules work!). Performing an Piwik API call in Python is as simple as:

1
2
3

def getVisits(idSite, period, date):
    url = "%s/index.php?module=API&method=VisitsSummary.get&idSite=%d&perio$
    return json.load(urllib2.urlopen(url))

Of course, as it’s Python its ridiculously simple!

Of course, if you find something that you can’t do with the API (which is unlikely, because it seems to cover everything), the you can access the data in the database – because it’s in YOUR database. You can also back-up and secure your data exactly how you want to. This is something that GA just can’t compete with!

5. Overall Impressions

My impressions of Piwik as a project have been really good. The documentation is excellent and there seems to be a good community behind it. As a product its a pleasure to use, really easy to install and just works. The reliance on flash for the graphs is a bit disappointing, but perhaps this will change in the future as HTML5 matures. Here are the obligatory scores:

• Installation and Setup – 5/5
• Site Integration – 4/5
• User Interface – 3/5
• Extensibility – 5/5

Overall Score: 4/5

Verdict: If your currently using Google Analytics, stop it! (and use this instead)

I’m going to try something different today. This is going to be the first in a series (hopefully once weekly) of Python Modules of the Week. This has probably been done to death elsewhere, but I’m using it as an opportunity to learn some more Python and to cement some of these modules in my mind.

Argparse is a Python module for processing command line arguments. It’s new in version 2.7 and is designed to replace the Optparse module. I’m not sure what the rationale for the change was as the two modules look very similar to me. However, it suffices to say that you should use argparse in all new code.

The main class of argparse is called ArgumentParser, it allows you to add arguments to your program and parse the provided arguments at runtime:

1
2
3
4
5
6

parser = argparse.ArgumentParser()
parser.add_argument("-v", "--verbose") # a flag type argument
parser.add_argument("value", type=int) # an integer positional argument
...
args = parser.parse_args() # parse the args from sys.argv
print(args.value) # arguments accessed as data members

You can also add meta-data such as help and descriptions to your arguments via keyword arguments to many of the methods. Take a look at the module documentation for examples. Once nice thing is that when you provide this data, argparse automatically generates the -h and –help flags and populates them with nicely formatted help output using the info you provide.

The argument parsing provided by argparse allows you to create some very complex command line interfaces to your scripts. I especially like the sub-commands framework, which allows each sub-command to exist as its own separate entity with its own options and help information. To create an argument parser with a sub-command is just a few lines:

1
2
3

parser = argparse.ArgumentParser()
subcommands = parser.add_subparsers()
mysubcommand = subcommands.add_parser('mysubcommand')

Of course,each sub-command is an ArgumentParser in its own right, so you can add all the options that you normally would, including command line flags, positional arguments and help information. Also each sub-command will be listed in the help and will also have its own help page which can be accessed via:

1

./pyprog.py subcommand --help

All in all, this is a very useful Python module to know about. Its ease of use and the number of things it ‘just takes care of’ make it a pleasure to use. Hopefully it’ll have you writing nice command line interfaces to all those hacked together scripts that are currently controlled by commenting bits of them in and out!

One of my major successes in this area has been in terms of feed reading. A while ago I setup rss2email on my server to check my feeds and email the stories to me. Previous to this I actually found it really hard to ever get around to reading news feeds. I think this was mainly because checking news feeds suffers from the ‘extra inbox problem’, its just more stuff to check. Having news stories emailed to me fixes this and I can also read them easily on my phone. Because I use IMAP email, my read/unread status is also synchronised on all my computers.

Now I’m kind of at a brick wall. I don’t know what else I can set up to reduce the number of routine tasks I do. The purpose of this post is to crowd source that problem. I want everyone reading this to get back to me with the things they’ve set up to help them. You can get in touch either through the comments on this post, or via identi.ca. If I get enough responses I’ll write a follow up post detailing some of the best ideas.

Anyway, it just so happens that the video that is up is from probably the best talk of the weekend, Anthony Baxter’s ‘Pythonic APIs’. This talk made me laugh from start to finish and taught me some things I didn’t know, watch the video below if you’re interested (brought to you by the magic of HTML5!).

As far as the other videos go, I’ve subscribed to the Kiwi Pycon Blip.tv RSS feed so I’ll be able to share them as they come along.

All that remains is to talk about my overall impressions of the conference, before they completely fade from memory! Basically I really enjoyed myself, everything was very well organised and the venue was excellent. There seemed to be some rumbling that Waitangi was a bit far away from everywhere and that the conference should have been in a city. For me the location was actually a bonus as it meant I had a good excuse to take the following day off and have a bit of a holiday!

So that’s about it, thanks to Danny, Guy, Tim and everyone else who organised. I had a great time and I even won a prize. I’m just sorry this post has taken me so long to get around to writing. Maybe I’ll be quicker off the mark next year!

Measuring ABV involves taking Specific Gravity (SG) measurements at the start and end of fermentation, adjusting them for temperature and pushing them into a simple formula. The SG measurements are taken with a Hydrometer, which is supposed to read at 20C (hence the need to adjust for other temperatures).

The temperature adjustment is done via a simple table (which I took from the book). In the script I used Linear Interpolation, to adapt it for values which weren’t available in the table. Initially I used the numpy.interp() function. However, I found that numpy isn’t present in SL4A and that installing it would be a pain since it is a C module which would need cross compiling for Android.

I therefore wrote my own interp() function, which keeps the same interface:

def interp(x, xp, fp):
    i = 0
    for p in xp:
        if p > x:
            i = xp.index(p) - 1
            break
    return ((x - xp[i])*fp[i+1] + (xp[i+1] - x)*fp[i]) / (xp[i+1] - xp[i])

I split up the code into two separate modules, sg.py (which just does specific gravity adjustment) and abv.py (which does ABV calualation). Splitting the code up enables me to take SG measurements and adjust based on temperature, without doing a full ABV measurement. In sg.py the reverse adjusted SG is what you would need to read from the hydrometer at the specified temperature, in order to achieve the adjusted reading you specified.

Since the calculations are fairly trivial the main bulk of the code is in the user interfaces. I implemented a simple command line interface which either takes arguments from the command line, or prompts the user via the python input() function. I also use the SL4A API to implement a simple UI for Android, basically the user is prompted for each quantity by a dialog box.

Anyway, there’s not much else to say, except that I’ve put the code up on Gitorious for anyone who wants it (it’s licenced AGPL). The code is in a git repository for useful Python scripts I’ve written, right now it’s the only thing there, but I’m going to track down some of the scripts I’ve written over the years and add them too – I might even get a few blog posts out of some of them!

OK, today I’m having a rant. This isn’t going to be an ill conceived rant about a company, like my last one. This one is about something of a general feeling that I’ve been getting recently. I want to talk about what I call Language/Platform restriction (I’m open to a better name). This can best be described by taking an example, the best of which is Android.

So, you want to develop an Android application, but you’ve got no experience in this area. So what do you do? You head over to the Android Developer site and read some of the tutorials and documentation. To your dismay you find all the code is in Java, but you’re a Python programmer. There doesn’t seem to be any way to use your favourite language on Android, despite everyone claiming that Android is an open platform.

Granted, this example is a little contrived. The chances of any developer not knowing that Android is a Java only platform are pretty small. This isn’t even my own experience as I’m pretty good with both Java and Python (though Python is my favourite). I guess my point is that developers have preferences over which language they like to use and that these preferences seem to be being largely ignored.

Now, Android does have a working Python implementation as part of the SL4A project, but this is very much a scripting environment not an application development environment. There is no native access to the Android APIs that are required to develop a fully fledged application. Also, in my opinion its usefulness as a scripting environment is limited by the lack of a Free Software cron equivalent, to run scripts automatically.

Lest you think I’m picking on Android, this problem isn’t specific to that platform. It’s also present on The Web. “Oh No!”, I hear you cry, “The Web is an incredibly open platform, you can use any language you want!”. In some ways this is true, on the server side, yes you can pretty much use any language you want (I’ve never seen any web apps written in assembly, but I’m sure it’s possible). The client side is another matter though.

If we restrict ourselves the technologies which make up “The Open Web” (basically ignoring Flash and Silverlight), we really only have one option: Javascript. Now, Javascript has historically been a complete mess. Granted it’s getting a lot better with HTML5, but it still kinda sucks. It doesn’t have any proper OO (please don’t offer up that “a function is an object” crap, as a sorry excuse). It’s still pretty low level, certainly compared to Python and it seems to be “the language which syntax forgot”.

This worries me. It actually worries me more than the Android situation. The reason for this is that I think The Web is going to be the main application delivery platform going forward and that Free Software needs to seize on this to create a suite of Free cloud applications, just as we have for the desktop. However, the lack of a choice of languages puts me (for one) off.

There have been efforts to port Python to the browser, specifically Pyjamas and Skulpt. There are problems with both these implementations. Pyjamas is too tied to its own application framework (which come from Google Web Toolkit) and it basically ends up bringing desktop like application programming to The Web. Maybe this isn’t a bad thing, but it seems to miss the full potential of The Web. Really what we need is something that takes advantage of all The Web’s APIs, but without having to use Javscript. Skulpt, although initially promising, does the compilation from Python to Javascript on the client side, thus multiplying the overhead in doing so by the number of clients (granted its distributed, but it still seems wasteful when this only needs doing once).

I should also take a minute to mention Google’s Native Client plugin. Although its not really part of the standard Open Web technology suite, it is trying to expand beyond what Flash and Silverlight offer. Basically it’s a way to run native x86 code inside a web application and expose methods through a Javascript API. You can potentially run anything in there. There are some continuing efforts to port Python to this platform, but I think this is the wrong way to go too. It’s not really intended to be a full runtime, its more like a sandboxed version of ctypes for Javascript.

In both these situations (Android and The Web) the best option is for native support for other languages to be added directly to the underlying virtual machine. However, this doesn’t look like it’s going to happen any time soon, so we might need some other solutions. Pyjamas and Skulpt have demonstrated that it’s certainly possible to compile Python to Javascript so I think that’s a low hanging target. I haven’t seen anything more promising than SL4A for Android yet, and porting dynamic languages to run on Dalvik strikes me as much harder (given the static nature of Java).

Throughout this post I’ve kind of focussed on getting Python to run on other platforms, but what I’ve said pretty much goes for Perl, PHP or any other language. If anyone has any thoughts on this topic, or details of other projects I should check out, please get in touch. My main fear is that we’re going to end up with a situation where there is not choice of programming languages for any given platform and that some of the best languages will be left out in the cold.

• Keynote: “Creating Pythonic APIs” by Anthony Baxter, from Google. This was really well put together, informative and above all hilarious.
• “How Python is influencing Neuroscience Research” by Daniel Myall. Again good to see python being used for hardcore sciencey stuff!
• “Don’t Block the GUI” by Glenn Ramsey. An introduction to basic threading and futures, I knew most of this stuff, but it was still interesting.
• “Python in the Datacentre” by Matt Provost, from Weta Digital. Interesting to see the internals of how Python loads, it probably explains why Python is slow on embedded systems too.
• “Wikkid Design” by Tim Penhey. About the design of a distributed Wiki system for Launchpad. Some good take home messages around choosing modules (personal recommendation and good documentation rule!).
• Open Spaces (Track 1): “Why aren’t we using Python 3″, “NoSQL Databases” and “Robotics and UAVs”.
• “Demystifying Unicode” by Leon Matthews. I knew nothing about unicode before this, now I know how to use it and that I should be using it!
• “Teaching Computer Science with Python” by Carl Cerecke. An interesting look into the Canterbury CS Department’s moves towards Python for teaching.

That’s it for now, there will be more in my full round up, which I’ll write when I have time (sometime this week). Bye for now!

So here’s the talks I attended:

• Keynote (obviously) – “How I learned to stop worrying and love deployment” by Jacob Kaplan-Moss (a core Django developer). This turned me onto a few modules, which I need to take a look at some point.
• “Freeing the Cloud one (small) service at a time” by Francois Marier – about free web services and his service, Libravatar, in particular (Francois was also kind enough to help me out with a problem I was having with it right there and then, thanks Francois).
• “Building a distributed Key-Value store with Cassandra” by Aaron Morton from Weta Digital. This was interesting, though I think a lot of it went over my head!
• “Packaging and Virtual Environments” by Brett Wilkins (and another presenter, who’s name I can’t remember – so sorry to him!). This was really good and turned me onto distribute, which is a setuptools replacement. I love the image on their website:

• Lightning talks – Of which the one on Bottle was particularly interesting – I’ve been looking for a lightweight web framework to play around with, so I’ll give it a try.
• “5 Good Reasons for Automated Testing” by Roman Joost. Yeah, I really should be using automated testing!
• “An Opinionated Guide to what makes a Good Unit Test” by Michael Hudson Doyle. Reinforced the opinion expressed above!
• “Amazon Web Service: An Introduction” by Simone Brunozzi. This was quite businessy, but this stuff is definitely on my “must check out” list.
• “Python In Astronomy” by Ian Bond. I missed the beginning of this but it’s awesome to see Python being used to do some hardcore science – finding planets no less!

Well that’s my quick summary of day one, hopefully there’ll be more good stuff tomorrow, so I’ll ‘see’ you then.