accessor/mutator functions

[mirandacascade]

When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Get<whatever> function)
2) for each data member, the class will have a mutator member function
(a Set<whatver> function)
3) data members are never referenced directly; they are always
referenced with the accessor and mutator functions

My questions are:
a) Are the three things above considered pythonic?
b) What are the tradeoffs of using getattr() and setattr() rather than
creating accessor and mutator functions for each data member?

[Michael Spencer]

mi************@ yahoo.com wrote:

When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Get<whatever> function)
2) for each data member, the class will have a mutator member function
(a Set<whatver> function)
3) data members are never referenced directly; they are always
referenced with the accessor and mutator functions

My questions are:
a) Are the three things above considered pythonic?
No
b) What are the tradeoffs of using getattr() and setattr() rather than
creating accessor and mutator functions for each data member?

Use property descriptors instead:
http://www.python.org/2.2.1/descrintro.html#property
http://users.rcn.com/python/download...htm#properties

Michael

[Simon Wittber]

> My questions are:

a) Are the three things above considered pythonic?

Python uses a function called 'property to achieve the same effect.
This example is taken from the documentation:

class C(object):
def __init__(self):
self.__x = 0
def getx(self):
return self.__x
def setx(self, x):
if x < 0: x = 0
self.__x = x
x = property(getx, setx)
In the above example, "C().x" would invoke and return the result of
..getx (the accessor), and "C().x = 10" would invoke .setx (the
mutator).

Are they considered Pythonic? Well, It depends on how they are used.
If you are using properties to perform some kind of type checking...
then the answer is probably No.

I've found that they are quite useful for implementing lazy evaluation
of attributes, which I would consider quite Pythonic.

Sw.

[mirandacascade]

If the class had two attributes--x and y--would the code look like
something lik this:

class C(object):
def __init__(self):
self.__x = 0
self.__y = 0
def getx(self):
return self.__x
def setx(self, x):
if x < 0: x = 0
self.__x = x
def gety(self):
return self.__y
def sety(self, y):
if y < 0: y = 0
self.__y = y
x = property(getx, setx)
y = property(gety, sety)

?

Because if so, does the term 'lazy evaluation' refer to the fact that
instead of:

C().getx()
C().gety()
C().setx(10)
C().sety(10)

one would substitute:

C().x
C().y
C().x = 10
C().y = 10

?

[Diez B. Roggisch]

> Because if so, does the term 'lazy evaluation' refer to the fact that

instead of:

No, it is a common technical term. It means that a value is computed the
time it is requested for the first time.

Like this:

class Foo(object):

def __init__(self):
self.__bar = None

def getBar(self):
if self.__bar is None:
self.__bar = some_lengthy_co mputation()
return self.__bar
That you can make bar a property of Foo is unrelated to this.

Another reason to use properties is if the value is always or at least
frequently a freshly computed one.
--
Regards,

Diez B. Roggisch

[Terry Reedy]

<mi************ @yahoo.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Get<whatever> function)
2) for each data member, the class will have a mutator member function
(a Set<whatver> function)
3) data members are never referenced directly; they are always
referenced with the accessor and mutator functions

My questions are:
a) Are the three things above considered pythonic?
As others have said, 'no', as in 'unnecessary because we have a better way
to accomplish the same purpose without doubling the attribute namespace'.
The purpose of the pattern is to hide the specific implementation of a
class (which attributes are static and which dynamic) and to allow that
implementation to change without changing programs that use the class.
Consider a complex class with interdependent .real, .imag, .rad, and .theta
attributes and the possible behind-the-scene implementations for what is
kept static and how they are kept synchronized. The need for get/set to
accomplish this in C++ arises from the fact that attribute names are
resolved at compile time, so that x.a syntax can only be used for simple
static attributes and access. Python, on the other hand, has means to
'magically' map what looks like direct attribute access into a function
call. First there was __get/setattr__ (which is awkward for multiple
dynamic attributes) and now properties with get/set/del for individual
dynamic attributes.
b) What are the tradeoffs of using getattr() and setattr() rather than
creating accessor and mutator functions for each data member?

--
http://mail.python.org/mailman/listinfo/python-list

[Michael Spencer]

mi************@ yahoo.com wrote:

If the class had two attributes--x and y--would the code look like
something lik this:

class C(object):
def __init__(self):
self.__x = 0
self.__y = 0
def getx(self):
return self.__x
def setx(self, x):
if x < 0: x = 0
self.__x = x
def gety(self):
return self.__y
def sety(self, y):
if y < 0: y = 0
self.__y = y
x = property(getx, setx)
y = property(gety, sety)

It could do - that works. One feature of this solution is that it leaves the
accessor/mutator functions in the namespace. That may be a good or a bad thing.
If bad, you could simply delete them after the property call (which is
probably better written as close as possible to the functions)

i.e., class C(object):
def __init__(self):
self.__x = 0
self.__y = 0
def getx(self):
return self.__x
def setx(self, x):
if x < 0: x = 0
self.__x = x
x = property(getx, setx)
del getx, setx
def gety(self):
return self.__y
def sety(self, y):
if y < 0: y = 0
self.__y = y
y = property(gety, sety)
del gety, sety

There are also recipes in the cookbook for defining property "suites" more elegantly

Note, that it is also easy to "roll your own" descriptor, which may be
worthwhile if you have a lot of similar properties, for example (not tested
beyond what you see):

from weakref import WeakKeyDictiona ry

class Property(object ):
def __init__(self, adapter):
"""adapter is a single argument function that will be
applied to the value before setting it"""
self.objdict = WeakKeyDictiona ry()
self.adapter = adapter
def __get__(self, obj, cls):
if isinstance(obj, cls):
return self.objdict[obj]
else:
return self
def __set__(self, obj, value):
self.objdict[obj] = self.adapter(va lue)

class C(object):
x = Property(lambda val: max(val, 0))
y = Property(lambda val: val%2)
z = Property(abs)

c= C()
c.x = -3
c.x 0 c.y = -3
c.y 1 c.z = -3
c.z 3

Michael

[Nick Craig-Wood]

Michael Spencer <ma**@telcopart ners.com> wrote:

mi************@ yahoo.com wrote:

When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Get<whatever> function)
2) for each data member, the class will have a mutator member function
(a Set<whatver> function)
3) data members are never referenced directly; they are always
referenced with the accessor and mutator functions

My questions are:
a) Are the three things above considered pythonic?

No

b) What are the tradeoffs of using getattr() and setattr() rather than
creating accessor and mutator functions for each data member?

Use property descriptors instead:
http://www.python.org/2.2.1/descrintro.html#property
http://users.rcn.com/python/download...htm#properties

Actually I would say just access the attribute directly for both get
and set, until it needs to do something special in which case use
property().

The reason why people fill their code up with boiler plate get/set
methods is to give them the flexibility to change the implementation
without having to change any of the users. In python you just swap
from direct attribute access to using property().

Also note that with property() you can make an attribute read only (by
defining only the get method) which is often the encapsulation you
really want - and that is something you can't do in C++.

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Dan Sommers]

On 28 Feb 2005 10:30:03 GMT,
Nick Craig-Wood <ni**@craig-wood.com> wrote:

Actually I would say just access the attribute directly for both get
and set, until it needs to do something special in which case use
property(). The reason why people fill their code up with boiler plate get/set
methods is to give them the flexibility to change the implementation
without having to change any of the users. In python you just swap
from direct attribute access to using property().

The reason their code is so inflexible is that they've filled their
classes with boiler plate get/set methods.

Why do users of classes need such access anyway? If my class performs
useful functions and returns useful results, no user of my class should
care about its attributes. If I "have to" allow access to my attributes
in order that my users be happy, then I did something else wrong when I
designed the class and its public interface in the first place.

I usually aim for this: if users of the public interface of my class
can figure out that I changed the implementation, then I've exposed too
much. Sure there are exceptions, but that's my basic thought process.

Sorry about the rant.

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
μ₀ × ε₀ × c² = 1

[Carl Banks]

mi************@ yahoo.com wrote:

When I look at how classes are set up in other languages (e.g. C++), I often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Get<whatever> function)
2) for each data member, the class will have a mutator member function (a Set<whatver> function)
3) data members are never referenced directly; they are always
referenced with the accessor and mutator functions

My questions are:
a) Are the three things above considered pythonic?
No. It's not good programming practice in C++, either.

If you have a class that's nothing but a big data structure, you ought
to use it as a data structure. Writing accessor and mutator methods
for its fields is just doing a lot of work to accomplish nothing.

If you want to provide access to a certain occasional field, but you're
concerned about keeping the interface backwards-compatible, go ahead
and use them. But try to observe the following rules of thumb:

1. Don't provide accessor or mutator function to every single member of
every single class you write. Only provide accessor/mutator functions
if the accessor/mutator methods are a sensible and useful part of the
class's interface.

2. Don't think of these methods as accessors or mutators. Instead,
think
of them as methods that access or mutate a certain abstract property of
the object that happens to be represented by a single member.

And, keep in mind that, since Python doesn't really have private data,
you don't have to worry about adding these functions to make debugging
easier.

b) What are the tradeoffs of using getattr() and setattr() rather than creating accessor and mutator functions for each data member?

Don't use getattr and setattr unless you have to construct the name of
the attribute at run time. That's what they're for.
--
CARL BANKS