Python Design Patterns

A friend pointed me to this talk by Brandon Rhodes on python design patterns from PyOhio a couple of years ago.

The talk asks an interesting question: why aren't design patterns seen and talked about in the Python community. He walks through the patterns in Design Patterns: Elements of Reusable Object-Oriented Software one by one, and points out some that are features of the language, some that are used in the standard library, and some that are really applicable. All with some nice small code examples.

The thing that got me thinking though was a comment he makes both at the beginning and end of the talk. The reason you don't see these patterns in Python is because Python developers tend not to write the kind of software where they are needed. They focus on small tools that connect other components, or live within a framework.

I'm a newcomer to the community, been doing Python full time for only a few years on OpenStack. So I can't be sure whether or not it's true. However, I know there are times when I'm surprised by things that I would have expected to be solved already in the language, or incompatibilities that didn't need to be there in the python 2 to 3 transition, and wonder if these come from this community not having a ton of experience with software at large code base size, as well as long duration code bases, and the kinds of deprecation and upgrade guarantees needed there.

Print Friendly, PDF & Email

2 thoughts on “Python Design Patterns”

  1. Something to keep in mind is that OpenStack is a pretty bad example of how to do Python for systems either large or small, so if most of your inputs on how Python people do Python are there, I don't reckon it's a great sample. Which is no diss on the great folk of OpenStack, rather that there is a whole wide world of Python.

    The arguments I've heard about Python not having/using design patterns come in two forms:

    * They're not there because you only need them if your language is broken (cf Java).
    * Many patterns are oriented around inheritance and abstractions that use inheritance. Where OO is warranted in Python, it is often for the sake of composition and other functional style is often better.

    Clearly neither of these are completely true.

    Nor do I think it is completely true that Python people only write small things, as we in the OpenStack clearly know. I think, however, that a lot of Python people wish most things could be small and interconnected rather than large and monolithic. I certainly feel that way, and get squeamish in the face of stuff that has not been adequately decomposed into its atoms (thus allowing the kinds of compositions described above).

    1. Sure, all of those are good points. It just struck me as interesting that it was central enough to his thesis that he stated it both at the beginning and the end of his talk.

Comments are closed.