30.03.20 15:50, jope...@hotmail.fr пише:
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`
No, it is not the same.
For example, `from os import mkdir as mkd` works, but `import os.mkdir
as mkd` is an error.
_
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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
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
_
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
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
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 t
joperez@hotmail.fr wrote:
> 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.
On Tue, Mar 31, 2020 at 12:12 AM wrote:
> 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 wi