On Tue, Oct 29, 2019 at 01:26:36PM -0000, mer...@gmx.net wrote:
> Yes :)
>
> That looks similiar to my problem, which i fixed for the moment of writing by
> renaming one folder.
> Basically, I would prefer if Python would not treat nth-level import fails
> different than first-level fails.
I think you mean that you would prefer if Python *would* treat nth-level
import failures differently. If the first level fails, the import search
stops immediately and raises; you want the import search to continue if
the second level fails.
> Might seem like a small thing, but in my opinion it would:
> - keep the behaviour straight forward
> - Correct the error messages, since from the perspective of the user the
> import actually DOES exist
> - Does not break anything currently working
> - Makes me happy ;)
I disagree with all but the last.
Think about the behaviour of ``from module import name`` in pure
Python. Currently, it is straightforward to explain:
try to import module, or fail if it doesn't exist;
name = module.name, or fail if the name doesn't exist.
With your behaviour, it becomes something complicated:
try to import module, or fail if it doesn't exist;
remember where we are in the module import search path;
try to set name = module.name;
if that succeeds, return;
else go back to line 1, but picking up the search from
where we left off.
Re your point 2, I'm a user, and from my perspective, if module.name
doesn't exist in the first module found, then it doesn't exist until I
move or rename one of the clashing modules. That's how shadowing works,
and I like it that way because it makes it easy to reason about what my
code will do.
But the critical point is #3. Any change in behaviour could break
working code, and this could too:
# 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
Same for the similar idiom:
try:
from module import name
except ImportError:
def name(arg):
# re-implement basic version as a fallback
I use those two idioms frequently. The last thing I want is for the
behaviour of import to change, which would potentially change the
behaviour above from what's tested and works to something which might
pick up *the wrong module* from what I'm expecting it to pick up.
You are asking us to change the behaviour of import in the case of
shadowing, to support a use-case which is (in my, and probably most
peoples, opinion) very poor practice. That has some pretty surprising
consequences:
from module import spam
from module import eggs
You would expect that spam and eggs both come from the same module,
right? Surprise! No they don't, with your proposal they might come from
different modules. That's going to play havok with debugging.
import module
from module import name
assert name is module.name
You would expect that assertion to be true, right? (Importing doesn't
copy objects.) Surprise! The assertion can raise AttributeError:
module.name might not exist even if ``from module import name``
succeeds.
I expect that with a bit more thought I could come up with some more
scenarios where the behaviour of Python programs could change in very
surprising ways.
So I will argue against this proposed change.
--
Steven
_______________________________________________
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/NC4EJDM7WPPIVK3ZGSQDPE3YH6C4KP2V/
Code of Conduct: http://python.org/psf/codeofconduct/
