Afternoon talks

I went to five more talks in the late afternoon and early evening. (Didn't think it was possible, but I'm almost Pythoned out!) Of the talks from the afternoon, these stand out:

Design Patterns and Python OOP: Objects by Design
Alex Martelli

Although the content was pretty redundant with some recent reading and discussion of design patterns I've been doing at work and at home, it was fun to see the Python in a Nutshell author speak in person. He went over some patterns like Strategy, State, and NullObject, showing how to implement them in Python. He gave the standard pitch for preferring composition to inheritance. In one twist, he made a distinction between two types of composition in Python:

1. holding, which basically means public exposure of a contained object and its methods/attributes. (outer.contained.Foo())
   
2. wrapping, which means exposing the desired functionality of the contained object through wrappers, and keeping the contained object itself private (outer.Foo(), which might call outer._contained.Foo())

Alex argued that we should prefer the second mechanism over the first, since that hides implementation details from our clients, freeing us to change the implementation in the future, etc. etc. I found this whole discussion kind of funny, because all the arguments for preferring "wrapping" over "holding" in Python are the same arguments for avoiding the use of public data members in, say, Java. It's just that in a language like C++ or Java, there's a long and hallowed tradition of "public data members == BAD" that no one even needs to speak about. I'm still new enough to Python that I don't know where the current culture and coding conventions came from. But I'm happy to see that there's little fundamental disagreement on sound OOP design principles across languages.

Alex also showed a couple of neat State implementations that work by changing __class__ or by rebinding individual methods. IIRC, the Gang of Four briefly mentioned such capabilities in languages like Self and Python when they were describing the State pattern in Design Patterns, and then for the rest of the chapter they described the more verbose hoops that folks using those "other" languages were forced to jump through. Hooray for Python! :)

One last thing Alex mentioned was his strong dislike of Singletons in Python or in any language. He recommended the use of Monostates instead, where you have as many instances as you want, but force them all to share the same state under the hood. He warned that Guido hadn't liked the idea, but said that he hoped to convince him. The implementation of Monostate went by too quickly during the talk, but the slides should be posted somewhere on the PyCon website. Alex also said that it was in the new edition of the Python Cookbook, which was incidentally released today.


Object-Oriented Design with Python
Bruce Eckel

Bruce started by covering the very basics of Python's OO capability (classes, instances, methods, static methods). He then made a couple of interesting points:

• In his opinion, problems with multiple inheritance and operator overloading in C++ weren't due to these features being "bad" -- they were due to the great difficulty in getting these features right in C++. In these cases, C++'s constraint of backwards compatibility with C had given it a serious case of warts.
• Bruce used to think that interfaces were just for static type checking, and so therefore of course Python didn't need them. He's recently come around to the idea that interfaces are a way to find out more about a type before you call a method. They're "a way to communicate about the design." To be honest, my initial reaction was: "duh." :) But I think he was actually making a deeper point that I didn't quite get as he was running short on time.
• One final idea: he thinks that adapters might be valuable as first-class language constructs. As he points out, we can obviously get by without this (you can roll your own adaptor in a lot of ways), but "it might help."

Traits - The Next Generation
David Morrill

David's talk turned out to be great, but as I mentioned to him afterwards, he should probably flip it around. It started with a description of these Trait things I'd never heard of, which made them sound like nice __setattr__ and __init__ hacks. But by the end of the talk, he was doing some really impressive GUI building and GUI-based attribute setting. If I understood correctly, he was basically showing us a dirt-simple way to express a strongly-typed data model as Python class definitions, and instantly have corresponding GUI and programmatic tools for dealing with that model. You get undo/redo and Python code generation for free. Traits is one of the Enthought Python tools.

One drawback: Enthought seemed a bit hesitant to publicize/release the thing. It is open source, but they're having build problems, etc. that make them antsy. It occurs to me that this is probably a pretty common chicken-and-egg problem in the open source world:

• Enthought worries that if they release before fixing all their problems, they'll be swamped with support requests that they don't have the manpower to handle, and/or a bad reputation for releasing something that's got bugs...
  
• ...but there were plenty of enthusiastic people at David's talk today that would be excited to pitch in and help fix these bugs...
• ...but enthusiastic people like that will never find out about your project in the first place unless you release and publicize it. :(
  

At any rate, the package looked very impressive, and I'm sure that Enthought will get some much-deserved credit when they do release.