Skip to main content

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.


Martin Chilvers said…
Some of our library is ready to release. Some isn't. Traits falls (mostly) into the former category, and the only things holding us back right now are build/packaging issues that require time and effort here at Enthought to fix (ie. adding flocks of external developers would not make any difference, 'excited' or otherwise).

Popular posts from this blog

PyCon 2018 Call for Proposals is Open!

It’s here! PyCon 2018’s Call for Proposals has officially opened for talks, tutorials, posters, and education summit presentations. PyCon is made by you, so we need you to share what you’re working on, how you’re working on it, what you’ve learned, what you’re learning, and so much more.

Before we dive in, the deadlines:
Tutorial proposals are due November 24, 2017.Talk, Poster, and Education Summit proposals are due January 3, 2018.Who should write a proposal? Everyone!

If you’re reading this post, you should write a proposal. PyCon is about uniting and building the Python community, and we won’t advance as an open community if we’re not open with each other about what we’ve learned throughout our time in it. It isn’t about being the smartest one in the room, so we don’t just pick all of the expert talks. It’s about helping everyone move together. “A rising tide lifts all boats,” if you will.

We need beginner, intermediate, and advanced proposals on all sorts of topics. We also need b…

PyCon 2018 Launches New Site, Sponsorship Search

After two great years in Portland, PyCon is shipping off to Cleveland for the 2018 and 2019 renditions of the Python community's largest gathering. PyCon 2018 will take place May 9 through 17 with two days of tutorials, three days of talks, and four days of development sprints.

For more information, check out our newly refreshed website at and follow us here on the blog and at @pycon on Twitter.

New Website

The new site features a design centered on the historic landmark Terminal Tower, a 52 story skyscraper that overlooks downtown Cleveland. When it opened in 1930, the tower was the fourth tallest building in the world and the tallest building outside of New York City. Though its height no longer tops the charts, the tower and surrounding Tower City area remain highly important to the city. What once was a beacon to guide ship captains to Cleveland's port and airplane pilots to its airport, the tower now includes 508 LEDs that light up for the holida…

How to get ready for the PyCon development sprints

[A guest post by Kushal Das, one of the 2016 Sprint Coordinators]So — you have already decided to join in the PyCon development sprints! The sprints run for four days, from Thursday to Sunday after the conference. You do not have to be registered for the conference to attend the sprints! Some teams plan to write code over all four days, while some projects plan a shorter sprint if the organizers cannot stay for all four days.Can you start getting prepared for the sprint ahead of time? Yes!There are several things you can do ahead of time, that can save effort once you arrive at the sprints — and some preparations can even be made at home, before you arrive at PyCon:Have your operating system updated and patched — whether Mac, Windows, or Linux. This eliminates one possible source of problems with getting software up and running.Go ahead and install the version control system that will be used by the projects you are interested in. If you install both git and Mercurial on your computer…