Module Structure/Import Design Problem

[Stef Mientki]

Rafe wrote:
> On Nov 21, 2:36 am, Stef Mientki <stef.mien... at gmail.com> wrote:
>   
>>>> 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
>> cheers,
>> Stef
>>     
>
> I really don't understand what you are trying to accomplish in your
> article.
>
> I strongly disagree with this statement...
> "A second demand is that every module should be able to act as a main
> file by running it's main section."
> ...I am finding the best programs have only one entry point or
> interface (though some libraries can be useful from outside the
> package.)
At first the program already basically consists of 3 different user 
interfaces, MatLab-like, LabView-like, Punthoofd-like.
Then it maybe a matter of taste, but for the moment I've planned to have 
3 to 5 different IDEs (besides the main programs), but that might change 
when they are all finished.
It might be a matter of taste, but I think you'll be better of by an 
optimal dedicated IDE, instead of something like Word ( I estimate that 
I, as many others, use less than 1% of the items, so you can imagine how 
much time we spent on searching the right item)
>  Being able to run any file in a package seems like it
> creates a confusing user/developer experience. What kind of problem
> makes this solution applicable?
>
>   
Testing ...
... by others on other operating systems
... in combination with other Python versions
... in combination with other Library versions (the program interacts 
heavily  with wxPython, Numpy, Scipy, MatPlotLib, VPython, PyGame, PIL, 
Rpyc, winpdb, wmi , LXML., ConfigObj, Nucular, ...)
... automatically testing after modifications
> Next, you say...
> "...recursive searches for all subdirectories and adds them to the
> Python Path."
> ...it seems like you add every module in your packages directly to the
> sys.path. Doesn't this destroy the package name-spaces? For example, I
> have a module called 'types' in my package if I add that to the python
> path, 'import types' still returns the built-in 'types' module.
> Wouldn't this collision be confusing? Regardless, isn't putting the
> package in the right place enough? Please explain.
>   
Well I've to confess, I'm not a programmer,
And if I can program, well, I leave that up to you,
and is not very relevant, because I know I can make useful programs ;-)
But  I've to admit, I don't understand packages.
I've never experienced any collision,
but then I probably always use much longer, self explaining names than 
the build-ins.

This my directory structure ( no module names) , which only contains the 
program and its libraries.
A few paths are 1 or 2 levels deeper.
The " lang"  contains internationalization strings in normal python 
files (another 300 files per language ;-)
Now in my opinion, each module in each path should be able to reach any 
other module in this directory structure.
So other / better / simpler solutions are welcome.

cheers,
Stef

main_path
   |__ lang
   |__ sub_path1
        |__lang
        |__sub_sub_path_1a
            |__lang
        |__sub_sub_path_1b
            |__lang
        |__sub_sub_path_1c
            |__lang
   |__ sub_path2
        |__lang
        |__sub_sub_path_2a
            |__lang
        |__sub_sub_path_2b
            |__lang
...
   |__ sub_path8


>
> Cheers,
>
> - Rafe
> --
> http://mail.python.org/mailman/listinfo/python-list
>