This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Do not import modules in star-import when __all__ is not defined.
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.9
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, ethan.furman, gvanrossum, serhiy.storchaka, xtreak
Priority: normal Keywords: patch

Created on 2019-09-18 15:56 by serhiy.storchaka, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 16263 closed serhiy.storchaka, 2019-09-18 16:00
Messages (5)
msg352736 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-18 15:56
If __all__ is not defined in a module "from module import *" will import all keys from module.__dict__ which does not start with underscore. It can add undesired names to the current namespace. The common case is related to importing modules.

1. Importing modules which are imported in the original module for internal use. Every module usually imports several other modules, and since public module names are not underscored, they pollute the namespace of the module. To prevent leaking they names you need to import them under underscored name, like "import sys as _sys" (if you don't want to use __all__). This is cumbersome and makes the module code less readable.

2. Importing submodules. The problem is that the result depends on the history of imports. If you imported "module.submodule" before or if it was imported implicitly by other module, "from module import *" will import the "submodule" name. But if it was not imported before, "from module import *" will import the "submodule" name.

The proposed PR excludes modules from importing by star-import if __all__ is not defined.

Discussion on Python-ideas: https://mail.python.org/archives/list/python-ideas@python.org/thread/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/
msg352740 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-09-18 16:19
I feel that this is a relatively minor issue, and not worth breaking "working" code over. Some more pedantic tool like a linter or type checker would be a better place to start diagnosing this.
msg352745 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2019-09-18 17:15
I don't think this is worth the code breakage.

The advice already given is not to use `import *` unless:

- the module was designed for that usage; or
- you know what you are doing.
msg352747 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-18 17:41
I believe that significant part or even most of code is writing without using linters and type checkers. Python is too convenient for non-professional programmers. You do not need to declare all variables with their types to use Python and do not need to run a compiler/linker/checker after editing sources.

There was such mistake (using a module implicitly imported by star-import) even in the Python stdlib (fixed now).

This change would increase the quality of code if you do not use __all__ and do not have habits to write "import sys as _sys". It will not affect professional code. It is just a small step in the direction of been casual user friendly.
msg352748 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2019-09-18 17:43
It's the casual users' code that will break.
History
Date User Action Args
2022-04-11 14:59:20adminsetgithub: 82396
2019-10-07 09:16:38serhiy.storchakasetstatus: open -> closed
resolution: rejected
stage: patch review -> resolved
2019-09-18 17:43:54ethan.furmansetmessages: + msg352748
2019-09-18 17:41:01serhiy.storchakasetmessages: + msg352747
2019-09-18 17:37:45xtreaksetnosy: + xtreak
2019-09-18 17:29:23brett.cannonsetnosy: + brett.cannon
2019-09-18 17:15:12ethan.furmansetnosy: + ethan.furman
messages: + msg352745
2019-09-18 16:19:49gvanrossumsetmessages: + msg352740
2019-09-18 16:00:46serhiy.storchakasetkeywords: + patch
stage: patch review
pull_requests: + pull_request15856
2019-09-18 15:56:53serhiy.storchakacreate