Regression of 3.13.1 for module paths in from import #127651
Description
Bug report
Bug description:
import os
print("FILE", os.__file__, os.__spec__)
def localImportFailure():
try:
from os import listdir, listdir2, path
except Exception as e:
print("gives", type(e), repr(e))
print("From import that fails in the middle", end=" ")
localImportFailure()This code outputs with 3.13.1 the following:
FILE C:\Python313_64\Lib\os.py ModuleSpec(name='os', loader=<class '_frozen_importlib.FrozenImporter'>, origin='frozen')
From import that fails in the middle gives <class 'ImportError'> ImportError("cannot import name 'listdir2' from 'os' (unknown location)")
As you can see, the __file__ and __spec__ values are fine. I found this in a regression test of Nuitka which worked with 3.13.1 and all Python versions before, giving the proper path from Python (which I use as a test oracle to know what the behavior to compare against is).
From my look at the code, this "unknown location" is coming from a code path, that tries to recognize shadowed stdlib modules, a new feature added in 3.13.1, can you please consider repairing it for 3.13.2, as I think file paths are very important part of exceptions for developers.
The issue is not OS specific. It only occurs with 3.13.1, not with 3.13.0.
CPython versions tested on:
3.13
Operating systems tested on:
Windows
Activity
picnixz commentedon Dec 5, 2024
We don't add features in minor versions. So it's either an undesired bug or something else.
Can you try with the latest main (not the released 3.13.1) and compile it from sources?
kayhayen commentedon Dec 5, 2024
Sorry, I didn't mean to offend you, I looked at the sources. I saw a bigger diff that is largely concerned with adding
is_possibly_shadowingnext to the occurrence that I think it would have to be. This is of course not a new feature in everybody's book. I should have said code change. I only meant to say that this change is the likely cause of the regression and was not present when it was last working in 3.13.0I compiled 3.13.1 from sources when this happened, I saw it on the official 3.13.1 Windows download as well, and I first noticed it when GitHub Actions recompiled their Python3.13 to be 3.13.1 on Windows and Linux.
I hope you don't mind if I share these link: https://github.com/Nuitka/Nuitka/actions/runs/12180424101/job/33974735672#step:7:372 and https://github.com/Nuitka/Nuitka/actions/runs/12180424101/job/33974734101#step:7:243 and I believe macOS was still using 3.13.0 on GitHubAction at the time.
I didn't use the
mainbranch yet, do you have reason to believe it's already fixed there, or is this just to confirm? I don't have the time right now, since I am scrambling to make a release that adds 3.13.1 support, but if necessary I will do it later this week. Sorry for asking that. I would even bisect the git bisect the actual commit if you want me to. But if you search "unknown location" in the source right now, it would have to be obvious from my report what code it is.picnixz commentedon Dec 5, 2024
I wasn't offended, sorry if it this is what you thought!
Actually I also didn't have a lot of time hence my questions! I just wanted to know whether you've already bisected or not.
Yup.
By searching "unknown location", I found the commit: 500f533 (thanks, didn't occur to me to do it...).
cc @hauntsaninja
pythongh-127651: Use __file__ in diagnostics if origin is missing
hauntsaninja commentedon Dec 6, 2024
Thanks for the issue and tagging me! Note for most users this will only affect frozen modules. Opened #127660
gh-127651: Use __file__ in diagnostics if origin is missing (#127660)
pythongh-127651: Use __file__ in diagnostics if origin is missing (py…
[3.13] gh-127651: Use __file__ in diagnostics if origin is missing (#…
pythongh-127651: Use __file__ in diagnostics if origin is missing (py…