Volume Number: 25
Issue Number: 04
Column Tag: Mac in the Shell

Mac in the Shell: Python: Getting OOPy with it

Or, delving into the real Object-Oriented Programming Features of Python

by Edward Marczak

The last several articles have been focusing on Python basics: data types, flow control, modules and more. Plus, the first "Learn Python on the Mac" article pointed out some Mac-specific tweaks needed to enable the built-in help docs. Here, we go a little deeper and talk about creating classes, Python's real Object Oriented Programming (OOP) powerhouse. This article will start to introduce OOP in general, and next month's column will get into Python specifics. Without further delay, let's begin.

Why OOP, indeed? I went back and forth for some time deciding if this was the right time to introduce the topic. There are plenty of other subjects relating to Python that I still haven't addressed. One can write perfectly competent, purely procedural Python programs without ever touching OOP directly. However, understanding OOP and having the class mechanism at your disposal is incredibly powerful. Also, if you ever want to get into GUI applications using Python as the language underneath, the ability to write classes is essential. Finally, those 'other topics' that I mentioned will come along in later articles, so, it will be good to get OOP into your brain sooner rather than later.

Essentially, classes are just another namespace packaging mechanism in Python. Typically, they provide a generic model of a real-world object. Classes promote reusability, and can cut development time. If you're coming to Python from C++ or Java, you're in for a surprise: classes in Python do away with some of the pomp and circumstance found in those languages. Like most things in Python, they're straightforward and easy to understand.

I've talked a lot about objects in Python in previous article, but we haven't really defined what that means. In one sense, you're using objects in Python if you know it or not. Python generically treats everything as an internal object. For example, when you make the assignment 'x = 'hello', x "is a" string object. On a more pedantic level, though, objects mean several things.

When you define a class, the class itself doesn't really do much. It acts as a model for instantiated objects. It's a factory that can churn out objects based on the namespace it contains.

Classes can inherit methods and objects from other classes.

Related to inheritance, objects can then extended an inherited class by adding new attributes and methods, or, override an attribute or method of the class it inherits from. Extending adds new behavior to the class. Overriding-also called overloading-changes the behavior of the method or class.

It all comes down to the dot operator, which we've been using all along to access module attributes and to call object methods (like a string method to strip whitespace). We've also talked a bit about namespaces. The subtlety behind the dot notation is that it forces python to perform an upward search, through the inheritance tree of namespaces. How does this work?

Last month, we talked about modules, and we can use that initially to illustrate. Take the following example:

#!/usr/bin/env python
x = 5
y = 7
def ModuleA():
  x = 12
  print 'In ModuleA'
  print x
  print y
print 'Main'
print x
ModuleA()

As you may expect, running this short program gives the following output:

Main
5
In ModuleA
12
7

Obvious? Perhaps. The main routine is asked to print x, finds x in its own namespace and does so. Then, we call ModuleA(), which first sets x, and is then asked to print x. Well, at this point, there are two x variables. So, the print statement in ModuleA() starts a search-from the bottom up-to locate x. It first looks in its own namespace, and finds x. Its own version of x, that is, and prints it. ModuleA() is then asked to print y. It again starts a search. Since it doesn't find y in its own namespace, it looks in the namespace directly above it. It finds y there and stops the search.

Note that in the above paragraph, it all comes back to namespaces. In fact, this search-though-the-namespace is initiated any time we use the dot operator in the object.attribute form.

As mentioned above, a class is just another Python mechanism of packaging up a namespace. Here's a simple Python class:

class ClassA():
  a = 5
  b = 7

Now, a slightly dirty secret is that a class really is just a namespace package, and we don't even have to instantiate it:

print ClassA.a

will do what you expect and print "5". You can even make further assignments:

ClassA.c = 9
print ClassA.c

Treating a class as a generic, function-like namespace sells the class mechanism a little short, though. Classes have the power to inherit attributes from other classes. Let's define another class:

class ClassB(ClassA):
  b = 44
  c = 88

In this case, ClassB inherits from ClassA. Essentially, all of the attributes from ClassA are copied into ClassB on creation. Let's instantiate three objects to illustrate:

inst_a = ClassA()
inst_b = ClassB()
inst_c = ClassA()

Note that both inst_a and inst_c are instances of ClassA. Each object has a variable a in its namespace:

print inst_a.a
print inst_b.a
print inst_c.a
5
5
5

When inst_b is instantiated, ClassB inherits from ClassA. This is why ClassB has an 'a' variable in its namespace. Figure 1 shows this graphically.

Figure 1: Class inheritance

When ClassB() is asked about variable 'a', it first searches its namespace. Not finding it, the search continues in the class it inherited from-also called its superclass-and the variable is found. We can alter these variables in our instance simply:

inst_b.a = 99
print inst_b.a

This will print 99, as you'd expect. However, it is only changed in the instance, not up the chain:

print ClassB.a
...prints '5'.

Creating an elegant object-oriented program takes some planning. That may be one of the key differences between a straight procedural based program, and an OOP-based one. OOP lets you be a bit more strategic. It also lets you build a larger app based on smaller, reusable objects. Next month, we'll dig into details and implementation a bit more.

Media of the month: "No Line On The Horizon" by U2. Now, this may be an obvious choice, a safe choice, or a polarizing choice. U2 has become pretty palatable to a broad audience these days. If you're one of those people that never gave them a shot, this is actually a decent album to start with.

Ed Marczak is the Executive Editor of MacTech Magazine. He lives in New York with his wife, two daughters and various pets. He has been involved with technology since Atari sucked him in, and has followed Apple since the Apple I days. He spends his days on the Mac team at Google, and free time with his family and/or playing music. Ed is the author of the Apple Training Series book, "Advanced System Administration v10.5," and has written for MacTech since 2004.