import and package confusion

[Scott David Daniels]

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.Daniels at Acm.Org