Is it better to use class variables or pass parameters?

[Derek Basch]

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

Flamewar....... .NOW!

jk, I really do want other opinions.

Thanks,
Derek

[Mc Osten]

On 1 Mar 2006 11:32:02 -0800, Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

I think there is no clear "general" answer. A criterion could be that
instance variables should be those who define the state of the object, that
define its "meaning".

About the others to me it's a matter of taste.

--
USB Priests for only 10$

[Dave Benjamin]

On Wed, 1 Mar 2006, Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

As a general rule, I only turn a parameter into an instance variable when
it would otherwise be a parameter of all (or nearly all) methods. Though
this is perhaps an overly mechanical perspective, I like to think of
instance variables as implicit parameters to every method. It helps me
keep scope under control and encourages better cohesion.

--
.:[ dave benjamin -( ramen/sp00 )- http://spoomusic.com/ ]:.
"one man's constant is another man's variable" - alan perlis

[Steven D'Aprano]

On Wed, 01 Mar 2006 11:32:02 -0800, Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

That depends on whether the variable is conceptually an attribute of the
instance or a parameter.

Attributes of the instance should be made instance attributes by (as you
put it) slapping a "self" in front of it. Parameters of the methods should
be passed around as arguments to the methods.
--
Steven.

[Terry Hancock]

On 1 Mar 2006 11:32:02 -0800
"Derek Basch" <db****@yahoo.c om> wrote:

This one has always bugged me. Is it better to just slap a
"self" in front of any variable that will be used by more
than one class method or should I pass around variable
between the methods?

My first reaction was that they should always be object
properties -- that passing values between methods of the
same object is always a bad idea. But on further reflection,
I'm not sure that's really the rule I use, so here's a
better attempt:

Are the values in question properties of the object?

If I make two calls to the object from unrelated processes,
should those values be the same, or different for each
caller?

If they need to be different for each caller, then you might
need to pass them around. If however, they are the same
because it's the same object, then they ought to be
expressed as properties of the object.

It's funny, I've never actually had any doubts about
which to use in practice, it always seems obvious, so
it's hard to recall what my actual thought process is
on the subject.

--
Terry Hancock (ha*****@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[James Stroud]

Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

Flamewar....... .NOW!

jk, I really do want other opinions.

Thanks,
Derek

I tend to think in terms of states. If a quantity/attribute is important
for the state of an object, then it should be an instance variable. If
it can be calculated from the state, then it can be made a read-only
property, etc. If it is irrelevant to the state of an object, it
probably should belong to another object or should be a global.

Here is an example from chemistry:

densities = {'H2O' : 1.0, 'Hg' : 13.6}

class CupOfLiquid(obj ect):
def __init__(self, liquid, volume):
self.liquid = liquid
self.volume = volume
def spill(self, spill_vol):
newvol = self.volume - spill_vol
if newvol < 0:
raise SpillError, "Can't spill that much!"
self.volume = newvol
def get_mass(self):
return densities[self.liquid] * self.volume
mass = property(get_ma ss)

Notice that it would be quite awkward to remember the volume state of a
CupOfLiquid instance between method calls. One would need a global to do
this, which defeats the purpose of using classes (i.e. object
orientation). Notice also that the value of densities is independent of
the state of any CupOfLiquid instance, so it is a global.

As an exercise, try threading this object for evaporation. Hint, you
might need a "lid_closed " attribute.

James

[Duncan Booth]

Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
or should I pass around variable between the methods?

Try to distinguish the state of the object from the parameters to methods.

An object should always have a consistent state. Say you call a method, and
that method calls a bunch of other methods. At almost any point during
those method calls execution can leak out to other bits of code (e.g. you
might think you are adding two values, but perhaps they have a user defined
addition operator) and that other code might just call methods on the same
object. This might not happen much in practice, but I think that if you
imagine all method calls as potentially happening in parallel it avoids a
lot of problems.

So, for example, if you had a method which returned a formatted
representation of something, and which took a precision as a parameter, you
shouldn't be saving the precision in the object: it isn't part of the
state, and if you save it as such one day you might find it changes under
your feet mid call.

A lot of objects benefit from being treated as immutable: i.e. initialise
them on creation, but never modify the attributes after creation. This has
the great benefit that you never need to worry about whether or not to copy
an object: you always just keep using the same object until an attribute
needs to change and then you just create a new one. Obviously this only
works for lightweight objects, but that should be most of them.

Passing one or two parameters around a host of methods is fine: if you are
passing more then it probably indicates you need to invent another object
to encapsulate the state associated with the method call. It is also likely
that it means you then want to move some of the code logic into the new
object. In other words, instead of:

obj.meth1(a, b, c, d) calls obj.meth2(a, b, c, d) calls obj.meth3, ...

(and perhaps meth2 only needs a, b and c so it can pass them on),
you want some helper object constructed with a, b, c & d and parts of the
original methods then get factored into methods on the help objects.

[bruno at modulix]

Derek Basch wrote:

This one has always bugged me. Is it better to just slap a "self" in
front of any variable that will be used by more than one class method
s/class method/method/

In Python, a "class method" is a method working on the class itself (not
on a given instance).
or should I pass around variable between the methods?

One of the first rules I learned (from experience...) was to restrict as
much as possible the scope of a variable. It usually makes code more
readable, more robust, and more modular. In fact, I sometime even pass
attributes of an object as args to a method of the same object, and/or
assign values returned from a method of an object to attributes of the
same object. This is more explicit than relying on side-effects.

So (as pointed by almost everyone in this thread...) the best criteria
here is : is this variable part of the state of an object, or is it just
a value used for a given computation ?

Note that if you find yourself passing the same huge set of variables
from method to method for a given computation, this may calls for a
refactoring... Python objects can be callable (ie function-like), so a
complex computation with lot of shared state (independant from the rest
of the object) may be best implemented as a separate temporary callable
object - which can take the calling object as a parameter if it needs to
access other attributes from it.

My 2 cents...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Derek Basch]

Wow! Thanks everyone. Such coherent and philisophical answers. I will
read them all over on a lazy sunday as this type ethereal stuff hurts
my head after about 30 seconds. All the gurus on the python list are so
friggin' smart. This should improve my coding after I digest it all.
Thanks Again!

Derek Basch

[Derek Basch]

So, if I am understanding what everyone is saying here. I should do my
best to distinguish between values that are part of the "state" of an
object and values that are more disposable and can change for each
computation of a value. So if I create an instance of a "wallet" class
and the color of the wallet is "red". The "red" value would be ideal as
a class variable as it is tied to the state of that wallet instance.
However, if the wallet class contains a function to compute the tax on
a purchased item, the purchase price would be a good example of a
passed parameter value. Am I on the right track?

Thanks,
Derek Basch