Python-list Digest, Vol 33, Issue 159

Ray Schumacher subscriber100 at
Sat Jun 10 19:17:06 CEST 2006

Thanks Larry,

My depth can really only get to ~3:
an usually not that.
It is shallow, with >hundred methods (mainly serial protocol defs for 
LX* telescopes), but it could grow I suppose.
I mainly see its use as an import for other, large apps.
Speed is not an issue here , just clutter, as you said.

I still also have not seen a written consensus on the "proper" usage 
of class variables. I define module vars (some constants), which I 
think is reasonable, although these modules are the type with only one class:
port = LXSerial.LXSerial(...)
My rationale of putting the class in its own module is to minimize 
giant module files with lots of long classes;  there is only a remote 
possibility that someone would want call a class without most of the 
others as well.


Ray Schumacher wrote:
 > > 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.

 > 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.

More information about the Python-list mailing list