"parent" in a class __init__ def?

[Ray Schumacher]

Thanks Larry,

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

I also have not seen a written consensus on the "proper" usage of 
class variables, if any. 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 one class in its own module is to minimize 
giant module files with lots of long classes;  I see only a remote 
possibility that someone would want call a class without most of the 
others as well.

Ray



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.