This doesn't really solve the problem imo. Imported symbols shouldn't be i 
portable elsewhere. Not by import * or explicitly. That's the problem. 

One could propose to fix this by doing:

1. Imported symbols and locally declared symbols are put in two different dicts
2. Deprecation warning when you import a symbol from the import dict of another 
module
3. At some future point promote this to an error

In this future re-exporting a symbol might be done with:

from foo import bar
bar = bar

There are other details like being able to programmatically access the import 
dict for example.

I'm +1 on this. 

> On 26 Jul 2019, at 19:43, Serhiy Storchaka <storch...@gmail.com> wrote:
> 
> From the description of the import statement in the language reference [1]:
> 
>> The *public names* defined by a module are determined by checking the 
>> module's
>> namespace for a variable named ``__all__``; if defined, it must be a sequence
>> of strings which are names defined or imported by that module.  The names
>> given in ``__all__`` are all considered public and are required to exist.  If
>> ``__all__`` is not defined, the set of public names includes all names found
>> in the module's namespace which do not begin with an underscore character
>> (``'_'``).  ``__all__`` should contain the entire public API. It is intended
>> to avoid accidentally exporting items that are not part of the API (such as
>> library modules which were imported and used within the module).
> 
> As an example of names which should be excluded from the public API the 
> reference mentions names of modules which were imported and used within the 
> module. And they are perhaps the most common cases. It is often imported 
> module names are the only non-underscored names which are imported by a 
> star-import by accident.
> 
> For example, modules re and sys were used in Lib/idlelib/editor.py but there 
> were no imports for them. This worked because they were imported implicitly 
> by `from tkinter import *`. [1]
> 
> There is other case when a module name can be occurred in the module 
> namespace: if it is a submodule. For example:
> 
>   >>> from xml.etree import *
>   >>> ElementTree
>   Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   NameError: name 'ElementTree' is not defined
>   >>> ElementPath
>   Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   NameError: name 'ElementPath' is not defined
>   >>> import xml.etree.ElementTree
>   >>> from xml.etree import *
>   >>> ElementTree
>   <module 'xml.etree.ElementTree' from 
> '/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py'>
>   >>> ElementPath
>   <module 'xml.etree.ElementPath' from 
> '/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementPath.py'>
> 
> Names imported by a `from xml.etree import *` are depended on importing a 
> xml.etree's submodule ElementTree. I do not think this is good.
> 
> I propose to change the rule for determining the set of public names if 
> `__all__` is not defined. In addition to underscored names I propose to 
> exclude names of modules.
> 
> In these rare cases where modules should be imported in a star import it is 
> not difficult to introduce `__all__`.
> 
> [1] https://docs.python.org/3/reference/simple_stmts.html#the-import-statement
> [2] https://bugs.python.org/issue29446
> 
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UPARIKB6LKNCROYUMDZSTP6BFLDOUF5V/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to