I’m not the Matt Wilson that disappeared from Rice University in 2008

This ain’t me:

There’s more than one matt wilson computer programmer out there. He went to Rice University, which is in Houston, my home town, but I went to University of Houston.

And he kinda looks like me. Especially when I was younger and skinnier.

So, it’s easy to see how search engines and people got us mixed up.

This article explains a little about what happened with him.

When he disappeared in 2008, I got a bunch of emails because people found my blog and they thought it was his blog. People wrote me messages telling me not to hurt myself, and that I’m loved.

Was nice!

Sometimes, when I’m bored and lonely, I search around on the internet for clues about what he is up to now. I’ve never found anything. I like to imagine he’s kicking ass, living in a solar-powered, organic farm somewhere, and he’s hacked all the satellites so it doesn’t show up on Google Maps, and he has lots of friends that care about him.

I just submitted my talk for PyOhio 2010

I’d be happy to get any crititicism ahead of the presentation. I’m hosting the code examples and the talk material here.

Building your own kind of dictionary

Python level: novice


My talk is based on a project that seemed very simple at first. I wanted an object like the regular python dictionary, but with a few small tweaks:

  • values for some keys should be restricted to elements of a set
  • values for some keys should be restricted to instances of a type

For example, pretend I want a dictionary called favorites, and I want the value for the “color” key to be any instance of my Color class. Meanwhile, for the “movie” key, I want to make sure that the value belongs to my set of movies.

In the talk, I’ll walk through how I used tests to validate my different implementations until I came up with a winner.

Unlike my talk last year on metaclass tomfoolery, and the year before that on fun with decorators (and decorator factories) I’m hoping to make this talk straightforward and friendly to beginning programmers.

You’ll see:

  • how I use tests to solve a real-world problem
  • gotchas with the super keyword
  • a little about how python works under the hood.

Extended description

I’m not done with the slides, but all my code examples are finished. You can read it all online at my github repository here.


  1. What kind of object I want
    1. Tests define the expected behavior
    2. How to run those tests
  2. First implementation (subclass dict)
    1. How the implementation is defined
    2. Examine test results
    3. Examine the C code behind the dict class to see why my subclassed __setitem__ method won’t get called from the parent class
  3. Composition-based implementation
    1. Explain composition vs inheritance
    2. Examine test results
    3. Point out irritating need to manually redefine every related dictionary method on the container class
    4. Show how to use __getattr__ to avoid all that boring wrapper code
    5. Show how __getattr__ doesn’t play nice with inspection tools
  4. UserDict.UserDict
    1. Explain implementation
    2. Examine test results
    3. Add a new test that uses this class as a parent for a subclass
    4. Explain how UserDict.UserDict is not a new-style class, so the super keyword behaves differently
  5. UserDict.DictMixin
    1. Explain implementation
    2. Examine test results
  6. PEP 3119 and why it is nice
    1. duck-typing, why it is awesome, why it isn’t perfect
    2. abstract base classes
    3. As of python 2.6, don’t use UserDict.DictMixin; use collections.MutableMapping

My metaclass article published

The November issue of Python Magazine has my article on metaclasses. I regain the rights to my text after 3 months, so I’ll be posting sections of that article here as blog posts over the next year.

In the meantime, I’d love to hear critical feedback so that I can improve the material.

Or if you want to write a message telling me how awesome I am, that’s cool too, but I would prefer you give me money. In fact, that applies to people that want to call me an idiot. You also should just give me money.

My proposed talk for PyOhio

Here’s what I submitted for a presentation topic for PyOhio:

TITLE: Decorators are fun

EXPERTISE LEVEL: Hopefully, there will be something for everyone. Novices might enjoy the material at the beginning mostly, while experts would likely be more interested in the ruledispatch discussion.

SUMMARY: This talk will start with a friendly walkthrough of decorators for people that have never seen them, then go into some straightforward examples, then finish with a review of how decorators are used in Philip Eby’s ruledispatch package.


  • The simplest possible decorator.
  • Pass arguments to a decorator.
  • Write a decorator and still preserve the function signature of the decorated function.
  • Coerce values into a function into types using decorators.
  • Log values coming out of a function.
  • Phillip Eby’s ruledispatch package implements generic functions, aka multimethods, for python. I’ll walk through how he uses decorators, and why they’re such a good idea for this.

My article is finally online

Introduction to Python Decorators is available for you to read after you fill out the annoying registration form.

I have a few ideas for the next article. Do any of these seem interesting?

  1. Demystify metaclasses: use metaclasses to add camel-cased aliases for underscored method names, show how to automatically make methods into properties, and build a crude ORM.
  2. Explore logging with python, ranging from writing out to local files to setting up a syslog-ng server. Show how to use logging config files and filters.
  3. Build a prototype inheritance system into python. I got really interested in prototype inheritance when I studied lua. Prototypes make it really easy to change class-based behaviors at run time.

Finally, the meaning behind the pirates-vs-ninjas debate became clear to me during a recent nitrous-oxide haze (no, not how you think; I was getting my teeth cleaned at the dentist). Anyhow, pirates and ninjas are symbols.

The ninja is a metaphor for the corporate employee. A ninja will get the job done or die trying. A ninja will kill everyone in his own family if he’s ordered to. A ninja has no sense of entitlement or dignity or flex time.

Meanwhile, the pirate is the entrepeneur, or maybe the upper-level executive. He has no sense of duty or honor. He seeks adventure and glory only. He’ll jump ship as soon as possible. He might even maroon his crew-mates on a desert island if it means he gets the treasure to himself.

Pirates love to hire ninjas because a ninja never disobeys. Ninjas love to kill pirates because they can pretend they’re killing their own pirate boss.