About

Welcome to Panela, Matt Harrison's take on mostly Open Source, Linux, Python, innovation in those areas, other buzzwords and Dick Proenneke. It comes complete with the illustrations as needed. Note the opinions expressed here are merely my opinions and not the opinions of my employer.

about Matt

Calendar

««Mar 2010»»
SMTWTFS
  123456
78910111213
14151617181920
21222324252627
28293031

Mailing List

My RSS Feeds








Bay Piggies meeting with Alex Martelli

posted 2005.05.19 Thu
I was lucky to get a seat (and dinner) at the standing room only presentation by Alex Martelli tonight. The talk, which was a repeat of his PyCon talk, called Python Design Patterns and OOP, was hosted by Google. His theme throughout the talk was that of delegation in OOP (object oriented programming), and who gets delegated what when programming. I'll provide an overview of what I gleaned. Design patterns referenced here should be available in the online Python Cookbook or the dead tree version which was authored in part by Martelli.

Hold vs Wrap

Holding and wrapping both involve encapsulating "sub-objects". They are distinguished that in the former the api intends for the user to call methods on and access the sub-objects directly, while the latter holds the sub-object in a private name and delegates calls to it through methods. Use wrapping as it allows for flexibility in swapping out the implementation as necessary. A good rule of thumb is if you have more than one dot (period) when accessing the encapsulating class, you are probably using "holding" which leaves the user hard-wired into an implementation.

Wrap vs Inheritance

Wrapping has an advantage over inheritance in that you can hide and restrict access to members. (Don't provide the user with too much power if it's not needed). Most oop programmers think that polymorphism is achieved only through inheritance, yet this is not the case for python. Because python uses "duck typing" (if it quacks like a duck, it's a duck, if it floats...), and polymorphism is based on signatures not classes, one is able to wrap and still achieve polymorphism.

Self delegation

Classes in python may delegate implementation within themselves by separating "hook" methods and "organizing" methods. An example Alex gave is the Queue class which has a "put" method that takes care of thread sychronization while accessing the queue (an organization method). Within the put method there is a call to "_put" which is a hook method. One may subclass or override the _put method if they want to control the storage of the item being "putted" but not worry about the threading issues. The UserDict class also allows for self delegation as the user must implement the "hook" methods, but have the basic skeleton for a class, and don't have to implement that plumbing.

Other Design Patterns

Alex discussed a few more patterns, namely Strategy (useful to use in place of a flag when implementing different levels of logging/debugging) and Null Object (replace the "if x is None:"). To cap it all off, Alex presented the difference between Singleton and Monostate (borg). He lamented that Guido was not present to be be convinced of the Borg's usefulness. (See the link above where Alex has commented about the differences between a singleton and the borg and why you probably want to use borg). All in all it was a well presented talk of pretty sound pythonic programming practices. I'm looking forward to his "black magic" talk in two months.

links: digg this    del.icio.us    reddit




1. a reader left...
2005.05.20 Fri 2:26 pm

Singleton and Borg both seem silly to me. Use a module global! Make the class "private", make that module global instance "public", and you're through. The Right Thing in Python is darn easy that people keep trying to complicate it to fill out a design pattern, but patterns are only descriptions of solutions; using the pattern to justify solving a problem no one actually has is all backwards.

Ian Bicking [ianb@colorstudy.com]


2. Matt left...
2005.05.20 Fri 3:28 pm

It sounds like you just have another implementation of a singleton (we don't have to call it that though ;)). Is there a recipe for that somewhere?

Alex also mentioned http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf for furthur discussion on the merits/drawbacks of singletons and monostate (though this pdf is java specific)