On Wed, Apr 29, 2009 at 01:12:33PM -0700, Scott David Daniels wrote: > Dale Amon wrote: >> I am trying to get to the heart of what it is I am >> missing. Is it the case that if you have a module C in a package A: >> A.C >> that there is no way to load it such that you can use: >> x = A.C() >> in your code? > OK, here's a simple question. What do you expect from: > import sys > sys() > sys is a module, and as such, it is not callable. > Just because you put a class inside a module, does not mean > that class magically does something by virtue of having the > same name as the module. > > A module is a namespace to hold classes, functions, etc.... > A package is a namespace to hold modules (possibly more). > > I don't understand why you don't use files like: > > VLMLegacy/ > __init__.py > Reader.py > VLM4997.py > WINGTL.py
Well, it is far more complex than that: I just cut it down to
the most minimal case I could.
> But, presuming some kind of rationale,
> put the code you want in VLMLegacy/VLM4997/__init__.py
That doesn't really do it. Perhaps I should try to describe
the situation better.
There are n different similar systems, each with multiple classes.
They could either be implimented as a class at the first level:
VLMLegacy
Condition.py
Plan.py
|
|
etc
but in that case each class will be filled with conditionals
that try to do the correct thing depending on which system's
data they are reading. That approach has already gotten *insane*
and I need to objectify things: put all the common code into
abstract superclasses, and then create a subclass for each
different system (of which there will be an unknown number added
over time), ie:
VLMLegacy/
Conditions.py Abstract classes
Plan.py
|
|
etc
TYPE1/ Subclasses of above specific to Type 1
Conditions.py
Plan.py
|
|
etc
TYPE2/ Subclasses for Type 2
Conditions.py
Plan.py
|
|
etc
|
TYPEn/ Subclasses for Type n
Conditions.py
Plan.py
|
|
etc
Every VLMLegacy.TYPEn.Conditions (or other class) has exactly
the same set of methods; each of those methods inherits much
of its basic behavior from VLMLegacy.Conditions.
If I make every subclass a unique name, things will
rapidly get out of hand, especially when I start
adding TYPEn+1,2... etc.
So yes, the approach isn't arbitrary, it is a solution
to real design problems which even the above does not
fully do justice to.
What I would really like to do when executing is more
like:
type = "VLM4997"
type.Header(args)
type.Plan(args)
type.Conditions(args)
Where the type might change from execution to execution
or even on different iterations.
signature.asc
Description: Digital signature
-- http://mail.python.org/mailman/listinfo/python-list
