"parent" in a class __init__ def?

[Ray Schumacher]

What is the feeling on using "parent" in a class definition that
class methods can refer to, vs. some other organization ?
Should all relevant objects/vars just be passed into the method as needed?
It seems like including "parent" in the class def is just like a
class variable, which most do not recommend.

An example:
class LXSerial:
def __init__(self, parent, debug=False):
...
def connect(self, port, baud=9600, ptimeout=10):
if self.debug:
self.connectedPort = StringIO.StringIO(':A#')
else:
if self.parent.model=='LX200GPS': ptimeout = 240
...

Ray

 

[Larry Bates]

What is the feeling on using "parent" in a class definition that class
methods can refer to, vs. some other organization ?
Should all relevant objects/vars just be passed into the method as needed?
It seems like including "parent" in the class def is just like a class
variable, which most do not recommend.

An example:
class LXSerial:
def __init__(self, parent, debug=False):
...
def connect(self, port, baud=9600, ptimeout=10):
if self.debug:
self.connectedPort = StringIO.StringIO(':A#')
else:
if self.parent.model=='LX200GPS': ptimeout = 240
...

Ray

Passing parent instance into a class is perfectly legal and is
used extensively in modules like wxPython GUI. It isn't really
anything like a class variable as the instance is normally
passed not the class itself. Each instance can have different
attributes. So if you have many parents with many children this
can be an effective way to structure them.

I think it depends on how deeply nested things get and how many
parameters need to be passed. I've used it when I want to
nest my objects more than 2 deep and I must pass around lots of
attributes. I find it is easier to just look "upwards" into the
parent to get the attribute than to clutter up my argument list
passing arguments deeper and deeper into the class hierarchy.
It can simplify the argument lists quite a bit. Maybe others can
comment with their thoughts as well.

-Larry Bates

 

[akameswaran]

I'm not sure how it's a comparison to class variables. So I wouldn't
worry about that. I think there are some advantages to having the
parent as an instance member. Intuitively, the name lookup on
self.parent.foo would be faster than if you passed in the object in
question - although I haven't tested this. In short, there's nothin
wrong with doin it - and it helps in many situations.

 

[bruno at modulix]

Intuitively, the name lookup on
self.parent.foo would be faster than if you passed in the object in
question

Each dot means doing a lookup in a namespace. The more dots, the more
lookups. And lookups do have a cost.

 

[bruno at modulix]

What is the feeling on using "parent" in a class definition

"parent" is just a name. What is the semantic for this name ? Parent
class (ie: superclass) ? Container ? Else ?

that class
methods

Takes care, "class method" has a very defined meaning in Python - a
class method is a method that takes the class object - not the instance
- as first param.

can refer to, vs. some other organization ?
Should all relevant objects/vars just be passed into the method as needed?

There's no absolute rule about this - at most some guidelines :
- What constitutes the state of an object should be an attribute of the
object.
- What is not part of the state and is only used for a given operation
should be passed as param.

It seems like including "parent" in the class def is just like a class
variable,

Here again, "class variable" has a well defined meaning in Python: it's
an attribute of the class object itself, that is shared by all instances
of the class.

which most do not recommend.

An example:
class LXSerial:

do yourself a favour : use new-style classes whenever possible.

def __init__(self, parent, debug=False):
...
def connect(self, port, baud=9600, ptimeout=10):
if self.debug:
self.connectedPort = StringIO.StringIO(':A#')
else:
if self.parent.model=='LX200GPS': ptimeout = 240
...

We still don't know what's the semantic for this 'parent'. But anyway,
having this test on self.parent.model smells of a design error. If the
timeout value depends on the 'parent' object, then it's clearly a
responsability of this parent object to know that value. Your code here
should read:

def connect(self, ....)
# ...
ptimeout = self.parent.timeout
# ...

You may also want to have a look at the strategy pattern, to avoid
cluttering your code with "if self.debug"...

wrt/ your original question, I don't see how one could give a sound
answer without knowing more about this "parent" object and it's
relationship with the LXSerial class/instance of.

 

[akameswaran]

Each dot means doing a lookup in a namespace. The more dots, the more
lookups. And lookups do have a cost.

hmm, intuition may not be right in this case.
Lookups do have a cost - now I"m almost tempted to write and run a test
for this - but the cost of each lookup is also relative to the current
scope. I haven't looked over the implementation of the python
interpreter - but I would hope the lookup on self would be optimized
and trivial. The next relevant question would be is it cheaper to
lookup self.parent or to look up a method variable, which I supsect
would depend on the number of names in self vs. number of names in the
method.

 

[bruno at modulix]

hmm, intuition may not be right in this case.

Lookups do have a cost - now I"m almost tempted to write and run a test
for this - but the cost of each lookup is also relative to the current
scope.

A common "optimization" trick is to 'localize' references before a heavy
loop, to avoid lookup cost, ie:

def method(self, *args):
dothis = self.dothis
dothat = somemodule.somefunc
CONST = othermodule.CONST
# heavy processing loop here

I haven't looked over the implementation of the python
interpreter - but I would hope the lookup on self would be optimized
and trivial.

It's certainly not trivial. Must take into account instance attributes
(in __dict__ or __slots__), class attributes, inherited attributes,
overriding descriptors, non-overriding descriptors, __getattr__, etc...
The incredible felxibility of Python's object model comes with a cost.

The next relevant question would be is it cheaper to
lookup self.parent or to look up a method variable,

The second - cf above.

which I supsect
would depend on the number of names in self vs. number of names in the
method.

Namespaces are mostly built upon hashtables, so the number of names
should be mostly irrelevant.