attributes, properties, and accessors -- philosophy

[Bruno Desthuilliers]

Ethan Furman a écrit :
> 
> Let's head towards murkier waters (at least murkier to me -- hopefully 
> they can be easily clarified):  some of the attributes are read-only, 
> such as record count; others are not directly exposed, but still 
> settable, such as table version; and still others require a small amount 
> of processing... at which point do I switch from simple attribute access 
> to method access?

Short answer : you don't !-)

Long answer : well, in fact you do, but the client code doesn't have to 
be aware that it's in fact calling an accessor.

Before we go into more details, you have to know that Python has a 
pretty good support for computed attributes, with both a simple generic 
solution (the property type) and the full monty (custom types 
implementing the descriptor protocol). So from the "interface" POV, you 
should never have an explicit accessor method for what is semantically 
an attribute (wheter the attribute is a plain or a computed one being 
part of the implementation).

Let's start with your second point: "not directly exposed but still 
settable". I assume you mean "not part of the interface, only supposed 
to be accessed (rw) from the methods" - if not, please pardon my 
stupidity and provide better explanations !-). If yes: Python doesn't 
have "language inforced" access restrictions (private / protected / 
etc), but a *very strong* naming convention which is that names starting 
with a leading underscore are implementation details, not part of the 
official interface, and shouldn't be accessed directly. Kind of a 
"warranty voided if unsealed".

So if you have attributes you don't want to "expose" to the outside 
world, just add a single leading underscore to their names.

First and third points are solved by using computed attributes - usually 
a property. The property type takes a few accessor functions as 
arguments - typically, a getter and a setter, and eventually a 
"deleter". Used as a class attribute, a property instance will hook up 
into the attribute lookup / setup mechanism (__getattribute__ and 
__setattr__), and will call resp. it's getter or setter function, 
passing it the instance and (for the setter) value.

This directly solves the third point. For the first one, the obvious 
solution is to use a property with a setter that raises an exception - 
canonically, an AttributeError with a message explaining that the 
attribute is read-only.

And for something more hands-on:

class Person(object):
    def __init__(self, firstname, lastname, birthdate):
        self.firstname = firstname
        self.lastname = lastnale
        self.birthdate = birthdate
        self._foo = 42 # implementation only

    def _getfullname(self):
        return "%s %s" % (self.firstname, self.lastname)
    def _setfullname(self, value):
        raise AttributeError("%s.fullname is read-only" % type(self)
    fullname = property(fget=_getfullname, fset=_setfullname)

    def _getage(self):
        return some_computation_with(self.birthdate)
    def _setage(self, value):
        raise AttributeError("%s.age is read-only" % type(self)
    age = property(fget=_getage, fset=_setage)


For more on computed attributes, you may want to read about the 
"descriptor protocol" (google is your friend as usual). This and the 
attribute resolution mechanism are fundamental parts of Python's inner 
working. Learn how it works if you really want to leverage Python's power.

HTH