There should be one-- and preferably only one --obvious way to do it. (from The Zen of Python https://www.python.org/dev/peps/pep-0020/) However, in something as basic as import syntax, that's not the case. This example comes from PEP 221 (https://www.python.org/dev/peps/pep-0221/) : A slightly special case exists for importing sub-modules. The statement `import os.path` stores the module os locally as os, so that the imported submodule path is accessible as os.path. As a result, `import os.path as p` stores os.path, not os, in p. This makes it effectively the same as `from os import path as p` Not only it doesn't respect the Zen of Python, but it's also quite counterintuitive because as explained in the PEP, the behavior of `import os.path as p` is not the same than `import os.path`, while `from os import path as p` is quite consistent with or without `as`. There is one case where `import ... as ...` is consistent (and justified IMHO), that's for statements like `import _thread as thread`, only the imported object is aliased (as `from ... import ... as ...` do). Looking at the standard library, only few dozens of lines match the regex `^import \w+\.(\w|\.)+ as`, while the other (equivalent) form has hundreds of matches. That's why I propose to restrict the aliased import statement (`import ... as ...`) to not be able to alias imported submodule, letting `from ... import ... as ...` statement be the only to do it. The roadmap could be to depreciate the statement with a warning in a few next releases, to remove finally remove the syntax. (hoping my English is okay)
There is no other advantage than respect of the Zen of Python (and I don't know how much it counts). Maybe it can simplify interpreter code, but I don't know about it and I doubt it. With that, it could help newcomers to Python to choose between the two syntaxes. (And I've already experienced team conflict about syntax) By the way, I think this issue is not fundamental, that's why a removal would actually maybe be too strong.
The part of "as X" of either "import foo.bar as X" or "from foo import bar as X" does _one thing_ and is fully self-consistent. The part of "import foo.bar" and "from foo import bar" does different things, that sometimes are interchangeable, and in some cases may have different results - however, these are well stablished, and overall, they don't even "care" or "know" if the imported part is to be renamed with an "as X" complement. For me that is "one obvious way to do it" and there is nothing of "oounerintuitive" on that. Also, trying to change or limit this now, besides blocking behaviors that sometimes are needed, would introduce severe backwards incompatibility for no gain at all. js -><- On Mon, 30 Mar 2020 at 11:54, Joseph Perez <joperez@hotmail.fr> wrote:
Maybe you should fill some feature requests to the linter projects, like flake8, so that they have an option to distinguish both ways so that one could point what is the "preferred way" for a given project. But I don't see any sense on even put a PEP 8 recommendation for this. On Mon, 30 Mar 2020 at 12:11, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
joperez＠hotmail.fr wrote:
`import ...` and `from ... import ...` does not behave in the same manner as it is explained in docs: https://docs.python.org/3/reference/simple_stmts.html#import. So they are not equivalent statements. `import os.path as p` and `from os import path as p` bind the same local name to the same object, that is true. However, they do in a quite different manner. And this difference can be relevant, for instance, when are dealing with circular imports (ok, I cannot remember any example of this right now). So I do not see how they are violating any principle in PEP 20 "The Zen of Python". Anyway, The Zen of Python is an inspirational document, not a law. Even it it was the law, any law has its exceptions and PEP 221 "Import As" presents and explains one useful exception. In my opinion... Thank you.
You are right, I did not envisage the case where you could have name mangling between submodule and variable inside package __init__.py, which could lead to different behavior. So my statement is erroneous and this thread is no longer relevant. Thank you
As spotted by response, I did not mature enough my point to see that they could have a slight difference between both statements. This thread is no longer relevant. Thank you
participants (6)
-
Chris Angelico -
jdveiga＠gmail.com -
Joao S. O. Bueno -
joperez＠hotmail.fr -
Joseph Perez
-
Serhiy Storchaka