Bruno Desthuilliers wrote:
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 !-).
Better explanation: attribute is publicly available, but buried a couple
layers deep in a private structure (yes, private structure name starts
with a leading underscore).
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
Very helpful, thank you. Hopefully my brain will be up to the
descriptor protocol this time... the last couple times were, um, less
than successful. :)
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
