Building your own kind of dictionary

Python level: novice

Description

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.

Outline

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

I’ll probably carve it up into a series of blog posts soon.

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.

• better
• more obscure
• crasser
• worse

You can see my netflix queue and become my Netflix Friend when you click on this link.

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.

OUTLINE:

• 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.

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.

Even though this check is not an advance on my awesome unfinished sci-fi novel*, it still feels really good to get a check and the liquor store clerk will cash it just the same.

[*] It’s like Star Trek meets the Breakfast Club.