Blogging at PyCon

I've been having a great time at PyCon! Good talk, catching up with lots of friends, and some renewed enthusiasm for the PSF. Greg Stein setup a blog for the Googlers at PyCon. Greg, Chris, Matthew, Will and I have been busy blogging about PyCon. I have more notes I'd like to post but my wrists can't keep up.

PyCon Lightning Talks

The lightning talks have always been one of my favorite parts of PyCon. They are an excellent way to start a conversation. It's just enough time to pitch one good idea and get people excited about it. There will be two sessions of lightning talks at PyCon this year -- Thursday after lunch and Friday after lunch. Please sign up for a talk by entering your name in the Wiki.

The first session is Thursday after lunch for 90 minutes. The second session is Friday after lunch for 60 minutes. If we could actually start a new talk every five minutes, that would be 30 talks between the two sessions. We'll have to get the speakers together and work out the logistics at lunch if it's going to work.

It would be nice to get someone to take notes on the session. It would require some lightning blogging. Can you write a sentence or two that captures the key idea of each talk and do it for each of the talks? If you can't, maybe the speaker should have been clearer about the take-home message.

What Do I Want to Learn at PyCon?

PyCon is coming! The most valuable part of the conference is connecting with people and catching up on their lives and work. As there have been more and more good talks, I've gone to fewer and fewer of them.

Another goal this year is to learn more about how people are using Python. I haven't had much opportunity to use the newer features of Python. I've never used or implemented a decorator. I haven't had much time to experiment with itertools and generator expressions. It's been a while since I've thought about metaclasses and whether there are good design techniques for using them. It looks like Alex Martelli is giving a couple of tutorial talks on these topics.

I think these would make ideal open space discussions. I'd love to see a session where people present some of their best example code and the audience asks questions and reviews it. A moderator could try to capture good design techniques and best practices. A good talk might cover similar ground, but I'm interested to see a diversity of approaches. If I can find some other people interested in these topics, I'll schedule some open space time for them.

There are also several talks I want to see. I've always favored talks about implementation techniques. There's a session with talks by Armin Rigo, Brett Cannon, and Jim Fulton that looks quite good. I'm also quite interesting to see Richard Saunders and Clinton Jeffery's work on profiling and visualization. Evan Jones is going to talk about some low-level work on obmalloc, which might be interesting, too.

I'm somewhat interested in the talk about Durus, an object database inspired by ZODB in the same way that Quixote was inspired by Zope; now that I'm not doing any ZODB development, the interest is primarily academic. I went to a talk about ATOP but didn't find it very satisfying because there was little discussion of the core design decisions for an object database. I should try to catch up with the developers this year and see how it is going.

Strategy vs. Hook

A colleague has reminded me a second time that a strategy object is better than a hook method. In principle, I agree, but somehow I fall back to inheritance and hook methods when I actually start to write the code. I must make a more conscious effort to use composition instead of inheritance.

The most recent example was so simple: We need to versions of an object, one with a lock to provide reasonable multi-threaded semantics and one without for applications that want every ounce of performance. I suggested having _lock() and _unlock() methods in the base class and having a subclass that actually provides the lock. The strategy alternative is to call self._lock.acquire() and self._lock.release(), but have _lock be a dummy object in one case.