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. -- http://mail.python.org/mailman/listinfo/python-list