Python-list Digest, Vol 33, Issue 159
Ray Schumacher
subscriber100 at rjs.org
Sat Jun 10 13:17:06 EDT 2006
Thanks Larry,
My depth can really only get to ~3:
package
module
module
error_module
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
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