Accessing class attributes: use methods only?

Is it general good practice to access and set class
attributes via
methods only, or is it okay practice to directly interact
with class
attributes? The professor in a class on Perl that I'm taking
suggested
that directly accessing and setting class attributes was a
bad idea.
Just wondering what the current preference in Python is.

Many thanks,
Chris
_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

Chris Lasher wrote:
> Is it general good practice to access and set class
attributes via
> methods only, or is it okay practice to directly
interact with class
> attributes? The professor in a class on Perl that I'm
taking suggested
> that directly accessing and setting class attributes
was a bad idea.
> Just wondering what the current preference in Python
is.
>   
Python goes by the premise that you won't go and muck around
in the 
class if you don't know what you're doing / need to,
but if you do need to, the programming language shouldn't
restrict you 
from doing so.
That's why there's no such thing as private.
Usually if the method has underlines before its name, the
programmer is 
trying to tell you you shouldn't access it unless you need
to.
Otherwise, I see no problem accessing data members outside
of the class.
The  main problem (that I see) lies in setting the
attributes:  F.E. if 
you had an array class that had an attribute called 'used'
that stored 
the # of in-use items
in most cases you wouldn't want to change this value, but
let the class 
handle changing it.
I hear in my CS classes that it's bad, but I think that's
partially the 
C++ mindset.
I don't see anything wrong with it.
It just may not be the easiest way to do it for certain
attributes.
But if you have csomeClassInstance.objidentifier =
"Some New String"
I think that makes more sense than wrapping that
functionality in a method.
You probably want to wait for someone else to answer,
because they'll be 
able to give you more information on whether or not it's
bad.
-Luke
_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

Chris Lasher wrote:
> Is it general good practice to access and set class
attributes via
> methods only, or is it okay practice to directly
interact with class
> attributes? The professor in a class on Perl that I'm
taking suggested
> that directly accessing and setting class attributes
was a bad idea.
> Just wondering what the current preference in Python
is.

Assuming you actually mean instance attributes, not class
attributes; 
i.e. an attribute that has a value for each instance of a
class, not an 
attribute that is shared by all instances...

Python practice is to use direct attribute access. If you
need to do 
something special when an attribute is read or set, you can
create a 
property. This allows you to define methods to be called
when the 
attribute is accessed, without having to change the client
code.

The use of getters and setters is popular in C++ and Java
where it is 
painful to change client code from direct attribute access
to indirect 
access through setters and getters. In Python there is no
need for this 
as the change only affects the class itself.

Properties are a somewhat advanced feature; here is some
more information:
http://www.python.org/download/releases/2.2/desc
rintro/#property

Kent

_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

Chris Lasher wrote:
> Is it general good practice to access and set class
attributes via
> methods only, or is it okay practice to directly
interact with class
> attributes? The professor in a class on Perl that I'm
taking suggested
> that directly accessing and setting class attributes
was a bad idea.
> Just wondering what the current preference in Python
is.
>   
I really like the simplicity of a.b = 3. I groan when put in
other 
environments where a method call is required.

And Python has the magic method __setattr__ to intercept
attribute 
assignment for the times where some inspection / protection
/ 
side-effect action is desired.

-- 
Bob Gailer
510-978-4454

_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

"Chris Lasher" <chris.lashergmail.com> wrote

> Is it general good practice to access and set class
attributes via
> methods only, or is it okay practice to directly
interact with class
> attributes?

Its generally good OOP practice to interact with object via
messages.
Its also good practice NOT to access an objects attributes
directly
(and that includes via get/set methods) A class should
publish a
set of operations. The attributes should be there to
support
those operations.

If you extract a value from a class, mess with it and write
it back
again thats *very bad* OO programming, don't do it. Its so
important
it even has a law named after it - the Law of Demeter...

That having been said, some objects responsibilities
include
exposing some data, but usually in those cases you want a
set
of data and it can be returned in a single method via a
tuple.
Similarly you can modify the data via a single call.
An example might be a Location class where rather than
having access to each field of the address you simply
create
an address by passing a tuple of values, read an address
by retrieving a tuple and modify an address by using the
full tuple. (This also ensures that validation of fields -
like
checking the post code still matches - can be done) But
you might also have other operations such as formatting
addresses. caculating distances between addressed (cue
the recent geo thread!) etc.

If you really must expose an attribute you should ideally
make it a property rather than a normal attribute.

> The professor in a class on Perl that I'm taking
suggested
> that directly accessing and setting class attributes
was a bad idea.

This is true in any OOP environment and the principles of
information hiding apply to classses as much as to modules.
But the really important issue is that classes should
express
an operationally focused interface not a data focusssed
one.
Most of the time you shouldn't know, nor care, what the
dfata
attributes of a class are. You send messages to get things
done, not to extract/insert data.

Polymorphism only works on methods, not data access.

However, one of Pythons core principles is it doesn't get in
your way.
If you really must access a bit of object state directly
Python lets
you and its not any more wrong than doing it by calling a
getX/setX method. get/set abuses information hiding almost
as
much as direct access.


PS. If you really want to find out why access to data is
bad
read Parnas' original paper on Information Hiding
(On the Criteria to Be Used in Decomposing Systems Into
Modules). Its probably on the web somewhere I'm sure.
Its from 1972, this isn't anything new... Wikipedia is also
a good source.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://ww
w.freenetpages.co.uk/hp/alan.gauld 


_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

On Tue, Feb 13, 2007 at 11:35:47PM -0500, Kent Johnson
wrote:
> Bob Gailer wrote:
> > I really like the simplicity of a.b = 3. I groan
when put in other 
> > environments where a method call is required.
> > 
> > And Python has the magic method __setattr__ to
intercept attribute 
> > assignment for the times where some inspection /
protection / 
> > side-effect action is desired.
> 
> The modern way to do this (since Python 2.2 I think) is
to use 
> properties. __setattr__ has other uses (for example for
delegation) but 
> it is too big a hammer for changing the behaviour of a
single attribute.

NTSAAB (Not to start an argument but) ...

Some of us old school types feel that properties are
non-Pythonic. 
They are a way to write code that does something that it
does not
look like that code is doing.  It hides your intend.  So, it
is not
explicit.

    "Explicit is better than implicit."
                   - Tim Peters
                     (see http://www.p
ython.org/dev/peps/pep-0020/)

In other words, properties are a way of writing code that
appears
harmless, for example:

    temp = weather.temperature

and:

    weather.temperature = temp

but making it do arbitrary, sneaky, gratuitous, and
egregious things.
See the documentation on the *property* function at
http://www.
python.org/dev/peps/pep-0020/.

However, some of you are probably saying to yourselves:
"Well, of
course (we're sneaky; we're devious; ...).  I mean we are
programmers, after all."

OK. OK. Maybe I had too much coffee this morning.

Dave

-- 
Dave Kuhlman
http://www.rexx.com/~dk
uhlman
_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

Thanks very much for your responses, all. Just to clarify,
yes, by
"through class methods" I actually meant
"through methods of instances
of a class".

Now for more discussion: I'm confused. On the one hand we
have Mr.
Kent Johnson's statement:

On 2/13/07, Kent Johnson <kent37tds.net> wrote:
> Python practice is to use direct attribute access. If
you need to do
> something special when an attribute is read or set, you
can create a
> property. This allows you to define methods to be
called when the
> attribute is accessed, without having to change the
client code.

So to paraphrase, he states it's the Python way to do:
my_instance = MyClass()
my_instance.x = 42

On the other hand, we have Mr. Alan Gauld, who states:

On 2/13/07, Alan Gauld <alan.gauldbtinternet.com> wrote:
> Its generally good OOP practice to interact with object
via messages.
> Its also good practice NOT to access an objects
attributes directly
> (and that includes via get/set methods) A class should
publish a
> set of operations. The attributes should be there to
support
> those operations.

So to paraphrase, he states it's the right way, regardless
of language, to do:
my_instance = MyClass()
my_instance.setx(42)

I'm used to just setting and getting attributes straight,
which would
be Pythonic according to Kent and yet also outright wrong
according to
Alan and academic papers. So is direct access actually not
Pythonic,
or is it Pythonic and Pythonistas spit in the face of
Demeter and her
lovely laws?

Curious,
Chris
_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

On Mon, 2007-02-19 at 18:31 -0500, Chris Lasher wrote:
> I'm used to just setting and getting attributes
straight, which would
> be Pythonic according to Kent and yet also outright
wrong according to
> Alan and academic papers. So is direct access actually
not Pythonic,
> or is it Pythonic and Pythonistas spit in the face of
Demeter and her
> lovely laws?

Kent and Alan can speak quite eloquently for themselves, but
just to
provide a more immediate answer, I expect they mostly agree
with each
other.

The issue isn't whether you code:
        my.x = 42
        or
        my.setx = 42

Alan is saying you should not generally be twiddling
attributes in an
object.

Kent is suggesting that if you do decide to twiddle
attributes in
Python, just do it directly.  If later on you decide you
need some
method logic to control the attribute twiddling, you can
use
        property
to invoke methods when directly accessing the attribute.  I
do not think
there is anything to be gained in Python by expecting your
object
interface to depend on the use of get/set methods.

-- 
Lloyd Kvam
Venix Corp

_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

"Chris Lasher" <chris.lashergmail.com> wrote

> Now for more discussion: I'm confused.


Actually there is no real contradiction. I'll try to
explain
and if I misrepresent Kent I'm sure he'll say so!

> Kent Johnson's statement:

>> Python practice is to use direct attribute access.
If you need to 
>> do
>
> So to paraphrase, he states it's the Python way to do:
> my_instance = MyClass()
> my_instance.x = 42

And this is quite correct. In fact I specifically said in my
reply
that if you really *must* access an attribute of a class it
is
better to just do it directly than to write setX/getX
methods

> On the other hand, we have Mr. Alan Gauld, who states:
>> Its generally good OOP practice to interact with
object via 
>> messages.
>> Its also good practice NOT to access an objects
attributes directly

So what I'm saying is that you should try to write classes
such that nobody ever needs to access the internal data. If
a
user needs access to the internals it is often a sign that
there
is some functionality of the class missing. Why do you need
the data? Shouldn't the class that owns the data do all the
manipulation of it? That's what OOP is supposed to be
about - creating objects which receive messages that tell
them what to do. Some of those methods will return data
values but you should neither know nor care whether they
are data attributes internally or whether they are
calculated
values.

> So to paraphrase, he states it's the right way,
regardless
> of language, to do:
> my_instance = MyClass()
> my_instance.setx(42)

No, I'm saying it's the wrong way regardless of language to
do that.
(With the exception of JavaBeans - and not all Java classes
need
to be beans! - because they rely on the set/get protocol to
support IDEs etc)

More usefully you should hopefully have a method that has a
meaningful, operation-based name, that results in the
internal
variable x being set to 42. But that should be a
by-product.
The user of the class should not, in general, even know
that
x exists!

Now that's in an ideal world and as such it doesn't exist.
So we
don't always have that luxury. And some objects are more or
less
just data stores - but they should be the exception not the
rule!
In those exceptional cases, if you need to access a data
attribute,
then it's OK to use direct access in Python.

> I'm used to just setting and getting attributes
straight, which 
> would
> be Pythonic according to Kent and yet also outright
wrong according 
> to
> Alan and academic papers. So is direct access actually
not Pythonic,

Direct access is Pythonic *when necessary*.
Direct access 9including via set/get) is wrong in an OOP
sense in
any language. The methods should expose a set of operations
which
do everything you need to do without your knowing about the
internals of the object.

> Pythonistas spit in the face of Demeter and her lovely
laws?

Nope, but Python allows you to break the laws in the
simplest
and most direct manner. One of Python's tenets is that we
are
all responsible programmers. When we break the laws of good
programming we do so in a deliberate way, fully aware of
why
we do it and of the potential consequences.

So both Kent and I are saying the same thing: don't use
setX/getX; use direct access if you have to. But I add the
caveat
that you should try to avoid the need for direct access in
the first
place.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://ww
w.freenetpages.co.uk/hp/alan.gauld 


_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor

Ah ha! All is clear, now. I understand what I misinterpreted
in your
first post, Alan. Thanks also to Lloyd for reinforcing the
concept.
Much appreciated!

Chris
_______________________________________________
Tutor maillist  -  Tutorpython.org
http://
mail.python.org/mailman/listinfo/tutor