[Tutor] import imports

[Alan Gauld]

"spir" <denis.spir at free.fr> wrote

> Here are some ideas around import. I wish to receive comments

> The module attribute __all__ allows defining names to be exported.
> I always use it for my own modules, and also sometimes define it in
> external modules, when absent, or adapt it to my needs.

I've never defined it in any of my modules. It encourages people
to use from X import * which is nearly always a bad idea.

> Then I'm happy with a secure "import *".

I'm not sure what you mean by a secure import *.
The only danger is that of name collisions and limiting the
exported names only helps by a tiny amount. There is still
a good chance that another module will have the same
name exported.

> ...unpracticle when a single change in an name export list has
> to be corrected anywhere else; there can easily be a whole
> chain or even a 'tree' of imports.

Exactly, thats why its a bad idea IMHO.
You can never predict what other modules your module might
be used with and to start customising other peoples modules
to your own envirohnment leads to madness in my view!

> "import *" is not recommanded for good reasons, as a
> blind and risky practice. Now, when this is done consciously,
> knowing that the imported module defines __all__, then
> the meaning is totally different, if not opposite.

Not at all. Two modules could still have conflicting names.
I don;t see how you  can avoid it. Thats why using import foo
is better.

import foo also has the advantage of forcing code to explicitly
flag where imported functions and classes are found. This
makes debugging and maintence far easier.
import * is a "bad idea" for all sorts of reasons.
Namespaces are powerful tools - lets use them.

> === package module lookup ===
>
> There is a similar issue at the package/application level:
> I do not know of any practice or feature that simply allows
> changing a filename, a directory name, or the organisation
> of the package's directory tree, without having then to
> correct all dependance information inside the concerned modules.

This is a more valid issue although if you always import both
package and subpackages directly and especially if you use
aliases to protect your code references from change

import foo as f

means even if foo changes name you only need to change
the import statement not all the references to f.x


> I would love a kind of import lookup to be based on the following 
> assumption:
> "The main/startup module resides in the package's root dir."

But most packages don;t have a startup or main module. They
are libraries that the application writer uses. Thus the app
writer provides the main or startup module not the package writer.

> This would also encourage the good practice of never
> writing absolute imports -- which is a plague.

I'm not sure what you mean by absolute imports. If you mean
giving the physical path to the file then You cannot really do
that in Python. I don't understand the comment?

> The purpose is python to know not only which modules exist,
> or which modules are intended to be imported, but also
> where actually they are -- or should be.

I thought it did that already? It looks in sys.path for modules
and when it finds them it sets the __file__ attribute if appropriate..

I got lost around here. I assume you are having problems
with modules that I've never encountered?

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld