The point is not that the proposed behaviour is *necessarily* bad in
this scenario, but that it is a change in behaviour.
Guess it would be a long debate to find out the pros and cons of that.
Any variant might in some case be more or be less desireable. What holds
still anyways is that module name shadowing is hurting many peoples in
unexpected ways. I read already multiple times when people were having
these issues, since they are unnoticed.
Python *could* recognize these shadowing cases and spill out a warning,
like: "Hey developer your module foo does actually exists multiple times
in import resplve paths (here, here and here). According to resolve
order (see: http://xyz) module (here1) will shadow the others"
People then could at least understand what is happening and don't
stumple upon the "its here, why Python tells me its not here?!"-effect.
Will not break anything and would only introduce a first-time importing
work.
Am 30.10.2019 um 22:00 schrieb Steven D'Aprano:
On Wed, Oct 30, 2019 at 12:54:13AM +0100, Richard Vogel wrote:
However, I don't see where
# Support many different versions of Python, or old versions
# of the module, or drop-in replacement of the module.
try:
from module import name
except ImportError:
from fallback_module import spam as name
might change a actual thing.
Case 1: Lets say "module" does not exist -> both fail
When you say "both", you mean under the current behaviour, versus the
proposed behaviour? And by "fail", you mean import from the fallback
module? If so, then you are correct, there is no change between the
status quo and the proposed behaviour for this scenario.
Case 2: Exactly one "module" exists but it does not contain "name" ->
both fail
Again, no change in the status quo.
Case 3: Multiple "module" exist. At least one having "name" inside
This is the scenario with a possible change in behaviour. To make it
clear, let's suppose we have two modules called "spam.py", which I will
tag as spam#1 and spam#2 (the tags #1 and #2 are not part of the file
name, just listed to aid understanding).
- spam#1 comes first in the path, and does not include "name";
- spam#2 comes second in the path, and does include "name".
The status quo is that importing "name" from spam#1 fails and so the
fallback version is loaded.
But under the proposed change in behaviour, importing "name" from spam#1
fails, but instead of loading the fallback version, "name" from spam#2
is loaded instead.
That's a change in behaviour. It could be an unwelcome one: just because
both files are called "spam" doesn't mean that they are functionally
equivalent. spam.name (from file #2) may be buggy, broken, obsolete,
experimental, or do something completely unexpected.
At the very least, it means that as the developer, there are two cases I
am aware of and have tested:
- load "name" from spam#1
- load fallback
but there's a third, non-obvious scenario I may have forgotten or be
unaware of:
- load "name" from spam#2
and consequently have never tested.
The point is not that the proposed behaviour is *necessarily* bad in
this scenario, but that it is a change in behaviour.
_______________________________________________
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/WJ4GBVMAJCPOD6OINLOGLUJ36YJH3LBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
