Wandering Thoughts archives

How I use objects in Python

Python may be object oriented but it is also very flexible, so flexible that you can use its objects for all sorts of different things, many of them not very object-oriented by conventional definitions. I am not a traditional OO programmer, so I tend to use objects in Python in mostly non-traditional ways and for a number of different purposes.

(By 'objects' here I mean roughly 'classes and instances of classes'.)

This list is not complete, but it covers all of the uses of objects that come to mind (which probably means all of my major uses of them):

• creating inheritance hierarchies for exceptions so I can have hierarchies of general and specific exceptions. I'm pretty sure that I'm usually overdesigning when I do this and that I rarely need an actual hierarchy as opposed to one or two separate exceptions.

• as data records, ie the equivalent of C structs, in situations where just a list or a dictionary isn't enough. This 'bag of data' design pattern probably horrifies real OO people.

• for polymorphism, when I have generic operations to apply to a variety of underlying object types. Usually I don't use much or any inheritance for this, because in Python you don't need to use inheritance to get polymorphism; you can just duck type.

  (This is a superset of objects as data records.)

• for combining data and behavior together when it seems to make things simpler. My ideal is when all of the code that has to know about internal data storage details can be most conveniently put in one place (ie on the class), but I am willing to put methods on the side of a bag of data when it makes dealing with the data simpler.

  (Sometimes this involves polymorphism.)

Note that I am a heretic and don't believe in encapsulation for the sake of encapsulation. As I wrote recently, I consider OO to be a code structuring technique. Even when I have classic style data+behavior objects, some of the code related to them may not live in their class, and I'm perfectly happy to have 'bag of data' classes that also have some convenience methods attached to them.

(One of the reasons that I like Python is that it is so laid back about 'OO style'. Duck typing, public members, and other things mean that you aren't forced to structure your classes and code in certain ways merely to interact with other code, unlike in languages where, eg, polymorphism is only possible through inheritance.)

PS: yes, sometimes my freewheeling ways result in me more or less blowing my own foot off over time. If you want a demonstration of that, the sprawling mess of DWiki is on githib.

Some stuff on Python 2.7.x support periods

It figures that shortly after I wrote The (future) problem with Python 2.7, I found out that the Python people had announced a release candidate for what will be Python 2.7.3 when it's released officially. The direct cause of this is likely some security fixes (especially the hash table issue), but it also includes quite a number of other bugfixes.

All of this made me realize that I didn't actually understand the normal Python support periods. The Python people have never made any explicit promises about this, but they have said some things. First off, the 2.7 release notes have a section talking about this, where they comment that two years has been their typical period for bug fixes. The only sensible way to interpret this is that the two years would normally run from the initial release of Python 2.7 on July 4th 2010; this puts the new 2.7.3 release just within the regular 2 year horizon but any likely future release outside it.

(Based on the documentation dates, previous 2.x versions apart from 2.6 have basically had close to a two year lifetime.)

Python 2.6 is an interesting exception to the past support intervals, in that it's still getting security fixes; the 2.6.8 release notes to be says that the Python people intend to provide security fixes for five years (counting from the initial 2.6 release). One could reasonably conclude that the 2.7 support period will be at least as generous. Personally I'm hoping for more generous; five years for security fixes alone would be better than nothing but not ideal. People who are still shipping Python 2.7.x in a few years will want not just security fixes but also fixes for bugs that have been stumbled over by their users.

(Leaving the bugs unfixed as an incentive for people to migrate to Python 3 doesn't work. Given the general issues with such a migration it just causes distributions to patch Python 2.7.x themselves. Linux distributions have very little hesitation about patching upstream software to fix sufficiently important issues; indeed, a declared 'no bugfixes' policy makes it easier in several ways.)