I ran into that problem a long time ago. It’s quite a Python wart. I don’t remember all the details, but basically the property is bound to the class it was created in and isn’t overriden for you automatically. Here’s the work-around:

class Foo(object):
def get_foo(self):
return ‘foo’

foo = property(lambda self: self.get_foo())

class Bar(Foo):
def get_foo(self):
return ‘bar’

print Foo().foo, Bar().foo

This will print “foo bar” instead of “foo foo” if you used property as you usually do. All we do now is delay the evaluation of self until the property is actually called, so it picks up the correct subclass instead of being bound forever to the class it was instantiated in.
return ‘bar’

No idea if Learning Python covers this or not.

Tic-Tacs: from what I’ve seen, __getattr__/__setattr__ seems like a much more popular way; I was wondering whether it was actually preferred or whether people generally just don’t know about property(). The potential issue I can see with __getattr__/__setattr__ is that the bodies can get cluttered if you’re trying to preserve an older interface with lots of types that have changed.

Thanks for the interesting replies so far! I love hearing other people’s thoughts on this.

Actually it doesn’t become private; __bar in class Foo is simply changed to _Foo__bar. This is not for encapsulation, but instead to prevent conflicts between classes and subclasses which both want fields with the same name which are not intended for public use. If you define “foo = Foo()” then you’ll still be able to say “foo._Foo__bar”.

But for the half of the world who doesn’t suck at programming, discipline and respect for public interface allows us to keep ourselves very content with Python. And really, accessing members directly isn’t a bad thing in Python, because if you *do* need to change it to a custom getter or setter, you can just add a __getattr__/__setattr__ and get on with you life.

(Python is great)

Frankly in a dynamically typed language its simply not needed because changing the internal type of the data member often does not break most public usage of the class. (Good unit tests will confirm this for you.) You will typically find the (proper) use of properties whenever you have a design-by-contract concept where the class method needs to check and guarantee certain variants. Just like real life, this is generally the exception rather than the rule and getters and setters turn out to be a lot of useless extra code and a “Bad Idea” TM.

So before going nuts with properties, just try accessing the data directly. Its ok – no one will make fun of you. Its a very “pythonic” thing to do. Then, on those rare situations where you do need more enforcement by your code – it will be very clear to other programmers that this matters because that property will stand out rather than just be one property amongst the many.

Keep your code very short, obvious, and elegant. I came to Python via C++ (and still love C++ which it seems most python folk do not) and it took me a while to abandon all that extra code which, while necessary in C++ – in python, didn’t really deliver me any extra business value and the compiler/environment and my project really would never use it. Things are different in a strong statically typed environment. Lose the extra class code and invest in unit tests instead. You’ll be much happier. But its good to know about properties cause they are priceless when you really need them…

Good luck!