[Tutor] [Python-ideas] import imports

[Alan Gauld]

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

> "Secure import" means that I, as client of the imported module,
> know that this module defines __all__. I can then safely import all.

I still don;t agree that simply defining __all__ means you can 
"safely"
import all. all restricts what the module exposes it does nothing to
prevent name clashes with other modules.

> So that there is no name collision (or rather no more than may
> happen inside a module when not paying enough attention to naming.)

If you carefully read the __all__ of every module you import.
Quite an onerous task that is completely unnecessaryy if you
use import foo instead.

> "Opposite" here points to the difference between blind "import *"
> and conscious import relying on the existence of __all__.
> And/Or the difference between knowing or not which names will be 
> imported.

OK, I agree that __all__ reduces the likelihood of inadvertantly
importing something you didn't expect (like a global variable say)

> I also think distributed modules or packages should be encouraged
> to define __all__ and that their doc should explicitely list which
> names are defined there.

Yes, if you are intending a package for distribution I would agree
that it would be good practice - even just to give basic protection to
foolhardy importers of all...

> : intra-package imports. Package/application developpers
> need to precisely specify the set of names that they import
> themselves from module to module, don't they?

Possibly, but if they too use import foo then again they will
have no such problems.

> Here, I'm rather talking of package or application maintenance.

I don;t see that it makes a huge difference except....

>.... even purely toolbox packages are identified by an __init__.py
> file that is considered as a startup module that will be parsed
> and executed before any module or sub-package import.

OK, Now I understand what you mean by startup.

> Even if my developpment is rather small-scale, I like to split
> it into modules and organise these into a properly shaped
> local directory tree.

I normally create a single folder and dump all my modules
into that. It will be under my $PROJECT area which has an
init.py file so is treated as a package and $PROJECT is
in my $PYTHONPATH. I don;t normally construct subfolders
for my modules, none of my Python projects have required
more than 10-15 files which is fine in a single folder.

But due to my use of Python I never develop packages
specifically for distribution, I am primarily a consumer
of packages not a producer.

> Now, I want to be free to move, rename, reorganise all
> of that stuff. What about you?

I wouldn't see that as a problem since I use the import
foo style almost exclusevely in production code Provided
the top level folder is in Pythonpath and the package has
init.py files my code will survive restructuring. Filename
changes are covered by using aliases on imports

> The proposal aims at letting this happen simply with
> either the developper or python itself, maintaining an
> up-to-date local module index for the application/package.
> Is it clearer?

Its clearer but still seems unnecessary to me unless you
insist on using from x import *.
But I'll leave it for those who are actually developing
packages per se to comment further.

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