I spent 2 hours tracking a bug yesterday caused by a bad habit I’ve realized I must break.

In Python I tend to create base classes to derive common functionality, a good practice. I also tend to set default attributes on the class, like so.

class Plant(object):
    species = 'not known'
 
class Kale(Plant):
    species = 'brassica'
    def __init__(self, name): 
        self.name = name

My intention is to create lots of Kale objects, some of them will be different varieties of Kale. The intention of the base class and even of the Kale class is to define some common methods and functionality more than it is to defined the data semantics which will be pre instance.

At this point I realize something, there can be multiple species of different plants, so I change my code.

class Plant(object):
    species = []
 
class Kale(Plant):
    species = ['brassica']
    def __init__(self, name):
        self.name = name

This looks kosher, but it’s not. The problem is that when I first modeled the data I was just initializing species so that it would always be set to something, the information was expected to change per instance. I was using the class to derive unique functionality, not define the data as a class inheritance hierarchy. But continuing to lazily initialize attributes per class which are really suppose to be per instance will end up biting me in the ass.

spear_kale = Kale("Spear Kale")
kai_lan = Kale("Kai-Lan") # A chinese form of Brassica oleracea
kai_lan.species.append("Brassica oleracea")

You see the problem now. When species was a string new instances of Kale that changed it would change the reference to species for their instance to a new string. Now that it’s a list and we are using append we are appending instance information to the class attribute and spear_kale and any other new Kale instances will have the kai_lan species info attached to them. The initialization of the species list should have been done in __init__ because, once modified, it’s actually information that is per instance not per class.

If I would have been using a list in the beginning I probably never would have created it as a class attribute. Since Plant doesn’t have an __init__ and it seemed like a good idea to default new subclasses to _something_ and I continued to use that pattern in defining the defaults all the way up until it bit me.

This illustration is pretty straightforward, but today I was debugging an issue in a default added to a base class of a wsgi application class and it took me 2 hours to figure out why an attribute being accessed in one web server was actually pulling an attribute that should only be accessible from a different web server in the same Python. It was painful and as a result I’ll be much more diligent about defined defaults that are per instance in an __init__ upfront instead of being lazy.

I was recently asked how to get unique lines from a text file in Python. The answer is so beautiful that I just had to post it.

unique_lines = list(set(open('filename', 'r').read().splitlines()))

For as long as I can remember there has been a huge hole where “Advanced Python” books should be. Recently Tarek Ziade published what I hope to be the first text to fill this hole with Expert Python Programming published by Packt.

The book starts off covering basic Python and tools installation (iPython, setuptools, etc). It quickly jumps to best practices which is a spring board for showing off many advanced Python features. By page 34 you’re at list comprehensions, this is my kinda book ☺

I like how the “Best Practices” subject naturally bleeds in to explanations of some Python internals and special class methods. Python is known as a “one way to do something” language but this is only true in the sense that there is always a “best” way to do something. By understanding list comprehensions, iterators, decorators, MRO, etc, you can easily show why one way to do something is better than the next and the context in which each should be used.

The book goes through great pains to try and explain the Python packaging and distribution process. At first I found the text to lack a clear linear line of process. It read like it was jumbled up, with each piece not really fitting in to the next and the whole thing felt very difficult and unintuitive. Then I realized it wasn’t the text that was lacking, but the current state of Python packaging. The sad fact is that Python packaging, distribution, and dependency management is terrible and the only work which seems to be close to solving this very real problem Is what Ian Bicking has been working on which started to take shape after this book was finished.

Certain sections of the book suffer from heavy selectivity. The version control section has a somewhat over simplified description of Centralized vs. Decentralized Version Control followed up with a short Mercurial tutorial. Why Mercurial? No clue. I use a half dozen version control systems on an almost daily basis and Mercurial is by no means the most popular. 

The book succeeds when it teaches the reader about Python and shows why certain strategies and tools work better than others. It fails when it explains textbook development methodologies and describes tools by way of workflow in said methodologies. 

The optimization section was great and, on it’s own, worth the cover price. Lot’s of tools I haven’t used before and now I can’t wait for someone to tell me some code is running slow enough that I need to dig in and use them ☺

It’s a good book and a must read for anyone who wants to be a better Python programmer. Like any book targeted at more advanced users you should be liberal about skipping sections based on your own expertise and at some points the book even encourages you to do so.

Did Jon Stewart just kick every main stream journalist’s ass?

But seriously, why has this invasion been completely unchallenged in the main stream media?

I’ve now had 4 Flip Video cameras. I had the Flip Ultra, then the Flip Mino which fell out of my pocket while riding my bike which I replaced with another Mino that was then stolen along with my laptop and bag a few weeks later.

At a certain point I figured I should just give up trying to own one. I hadn’t taken much video with any of them and throwing more money at it just seemed silly. With the holidays approaching I read about the new Flip Mino HD I decided to give the whole thing one last go.

The video quality is really good if you have good light but is a little worse than the old Mino in poor light. The quality is what you would expect from a quick point and shoot and the battery and hard drive seem to hold out for a little over an hour worth of video. 

The Mino is pretty damn small for a video camera but it certainly looks big next to my iPhone. It’s small enough to fit in that little extra pocket in my vintage Levis. The only bad news is that the little metal ring on the back side of the Mino is a bit abrasive and will scratch that backside of your iPhone if it’s in the same pocket.

Adam and I shot the video below to show his Dad how great the weather was even in November

Adams Drive Take Three from mikeal on Vimeo.

Using in iMovie

iMovie thinks it can import directly from the camera, but it’s wrong. You need to use the “Import Movie” function to import the movies from the mounted Flip’s drive and create a new event.

If you want to get the movies up on vimeo you should ignore the regular vimeo iMovie instructions as they are severely outdated. In the newest iMovie you’ll wanna go to Share -> Export Using Quicktime. Then use these advanced video encoder settings and after that make sure you set the Size to 1280×720.