Patterns in Python

This talk, by John Gregorio, our Google App Engine trainer, is about the lack of design patterns in Python. His first thesis is native features take care of a lot of them. If you have top-level functions, metaprogramming, iterators, closures, which we do ("sort of" closures), then you've covered a lot of them.

When it comes to concurrency, we still need some patterns. Does this mean adding new features. How about using channels instead of threads. Rob Pike's Google Talk is great on this. Let's look at pycsp.

Conclusion: if you're implementing a pattern, look for existing language features. If the pattern is missing, that's a place to think about new language features. Concurrency is a rich area of pattern design.

I'll go ahead and add about class decorators here too, a language feature that takes care of patterns.

Python 2.6 marks the start of when class decorators became possible. They're pretty much the same as function decorators. You can use them in place of metaclasses a lot of the time.

You'll keep the additional functionality outside the class definition, plus the code is way more readable and writable. The fact that you can stack them means you don't need metaclass inheritance, something Alex Martelli understands, but who else?

Patterns like Register, Augment, Fixup, Verify may be implemented with class decorators. Good talk, by Jack Diederich, the author of the class decorator PEP. Best practice: return the original class and don't assume you're the only decorator. You may still want a metaclass. Don't add __slots__ when decorating.

The ORM for web2py is pretty sophisticated, as is web2py in general -- the lightning talk was impressive. Here's a FOSS product that started in academia, with clear teaching a goal, and migrated outward as a maintainable project, or so it appears as of this writing. The project has lots of commiters, is not a private king in a private castle solo coder kind of thing (the hallmark of a "no future" project).

Guido is discussing Google App Engine's non-relational database, built atop Google's infrastructure. When you take the R out of RDBMS, what do you get? It's an object store, yes, but there's still a kind of SQL (a limited, minimal subset thereof).

Speaking of ORMs, Dejavu aims to stay more Pythonic, is less deferential to the SQL end of things. Like the other ORMs, it lets you define your database in Model classes, run queries and so on. It goes with GeniuSQL somehow (how? -- I came late).

Non-relational databases are hot these days. The SQLAlchemy and related camps are wisely choosing not to tackle those backends. Django is very focused on SQL engines, but given its pragmatic focus, it'll likely back end into CouchDB etc. pretty easily -- some experiments already under way.

Speaking of non-relational databases: good meeting up with Alan Runyan again, the Houston-based principal behind Plone. I joined his team at a sprint in Vancouver, BC that time, as a noob (newbie).

I had lunch with Jeff Rush and his wife Mary, the Pycon registrar. We had an encouraging discussion about Python's outreach to teachers. Jeff is on the PSF Board of Directors, is a former Pycon chairman (after Steve Holden). I'm a voting member of the PSF (not the executive board), as of yesterday. Other lunch chatter: Phillips Exeter is teaching Python these days (thanks Warren).

Google App Engine, which already looks like Django a lot, is motivating the SQL community to bridge to "non-relational" backends. Web2py, for example, talks to both back ends. It's easier to map relational applications to non-relational although what's the point sometimes. The panel is struggling with a lot of good questions.

This is my bread and butter in a lot of ways (databases), so I'm pretty interested in this discussion. Google's BigTable, Amazon's Dynamo, Tokyo Cabinet, CouchDB, HBase, MongoDB, Cassandra, Redis... there's no "killer" in this scene yet, according to our speaker Bob Ippolito of Mochi.

These schemaless key-value document data stores (memcached another one, no persistence) are a lot like Python dictionaries. Bob is explaining how distributed network datastores have a hard time supporting strict ACID when speed is a goal. BASE is a weaker standard, is "what everyone is doing" in the cloud these days.

The Pycon 2009 website is running on web2py atop PostreSQL this year.