"spir" firstname.lastname@example.org 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?