Regression of 3.13.1 for module paths in from import

[kayhayen]

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

Linked PRs

• gh-127651: Use __file__ in diagnostics if origin is missing #127660
• [3.13] gh-127651: Use __file__ in diagnostics if origin is missing (#127660) #127775

[picnixz]

a new feature added in 3.13.1,

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]

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_shadowing next 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.0

I 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 main branch 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]

Sorry, I didn't mean to offend you,

I wasn't offended, sorry if it this is what you thought!

I don't have the time right now,

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.

or is this just to confirm?

Yup.

By searching "unknown location", I found the commit: 500f533 (thanks, didn't occur to me to do it...).

cc @hauntsaninja

[hauntsaninja]

Thanks for the issue and tagging me! Note for most users this will only affect frozen modules. Opened #127660