Module Structure/Import Design Problem

[Rafe]

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.) 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?

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.


Cheers,

- Rafe