import and package confusion

[Dale Amon]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20090429/46d163ee/attachment-0001.sig>