Module Structure/Import Design Problem

[Stef Mientki]

Gabriel Genellina wrote:
> En Thu, 20 Nov 2008 17:36:11 -0200, Stef Mientki 
> <stef.mientki at gmail.com> escribió:
>
>>>> I'm not an expert, I even don't fully understand your problem,
>>>> but having struggled with imports in the past,
>>>> I've a solution now, which seems to work quit well.
>>>>
>>> That's not very helpful, is it? Were you planning to keep the solution
>>> secret?
>>>
>> sorry slip of the keyboard ;-)
>> http://mientki.ruhosting.nl/data_www/pylab_works/pw_importing.html
>
> May I reiterate my criticism to your "solution" posted last week?
You're welcome,
if there are better (even more important simpler) solutions, I'm in.
> I don't think extending sys.path to include every directory under your 
> project is a good idea. Basically, you're flattening the directory 
> layout, removing any structure, like it was before Python 1.5 added 
> package support.
> It is like dumping all your modules in a single directory, with no 
> hierarchy and lots of name conflicts.
Well I started at 2.4 and now arrived at 2.5, so I don't know what it 
was at 1.5.
And I'm probably going to stay at 2.5 for a long time, upgrading is one 
of the few (maybe the only) disadvantages of Python ;-)
For Python, I guess you're right, all files are in one flat directory, ...
... but it's just 1 program, so what's the objection ?
For the program itself, which is highly dynamic, it can find sets of 
python-files in certain subpaths,
so that's quit ordered I think ?

> Worse: because your proposal makes the same file reachable under many 
> different names, the *same* source module will generate *different* 
> module objects stored as *different* entries in sys.modules. Globals 
> don't work anymore, subclasses aren't subclasses... lots of problems.
Could you explain this a little more ...
... I'm just adding every subpath to the Pythonpath,
so in my ignorant believe, every module is imported the same way, but I 
might be wrong.
" Globals not working" , a good program doesn't have any globals ( said 
a non-programmer ;-)
Subclasses aren't subclasses ? ( I always derive subclasses in the 
module itself, or in the same directory as the parentclass)
> Relative imports (PEP328 [1]) were introduced -among other things- as 
> an attempt to avoid such problems. You're going in the opposite 
> direction. Please stop doing that - or at least keep us informed of 
> where you work!
>
> [1] http://www.python.org/dev/peps/pep-0328
>
Sorry I don't understand all that pep-talk (I'm not a programmer ;-)
I read it starts with " For the second problem, it is proposed that all 
import statements be absolute by default (searching sys.path only) with 
special syntax (leading dots) for accessing package-relative imports."
I think that's exactly what I'm doing: absolute imports.

Please explain in simple language what I'm all doing wrong,
or how I get a better solution.

thanks,
Stef