Dale Amon wrote:
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.
You did not answer the question above, and I think the answer is the root
of your misunderstanding. A class and a module are _not_the_same_thing_.
sys is not a package, it is a module.
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
Unlike Java, we are free to have several things in a module:
several classes, several functions, several constants....
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...
But VLMLegacy.TYPEn.Conditions is a _module_, not a _class_.
I suggest VLM4497.py look a bit like the following:
from VLMLegacy import abstract_classes
class Condition(abstract_classes.BaseCondition):
...
class Plan(abstract_classes.BasePlan):
...
Header = abstract_classes.BaseHeader # Note we needed no customization
...
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.
Well, "VLM4997" is a _string_, and it has no attributes (nor methods)
named "Header", "Plan", or "Conditions." And "type" is a perfectly awful
name for a variable, since it hides the builtin named type. You seem to
confuse names, files, and classes defined in files (at least in your
writing).
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
