Likely duplicate of #60115

Likely duplicate of #60115

Definitely related inasmuch as importlib._bootstrap is involved, @exarkun is the user I mentioned in my report. Note that the issue does happen with other frozen modules, though, so the scope of the problem is expanding in 3.11 because of #89183. Here's an example showing the same problem with os.path

# repro2.py
import os.path

os.path.basename("/foo/bar/baz.py")  # implemented in Python

With Python 3.10:

$ python3.10 -m pdb repro2.py 
> /home/snoopjedi/repos/cpython/repro2.py(2)<module>()
-> import os.path
(Pdb) n
> /home/snoopjedi/repos/cpython/repro2.py(4)<module>()
-> os.path.basename("/foo/bar/baz.py")  # implemented in Python
(Pdb) s
--Call--
> /home/snoopjedi/.pyenv/versions/3.10.0/lib/python3.10/posixpath.py(140)basename()
-> def basename(p):
(Pdb) l
135         return p[:0], p
136  
137  
138     # Return the tail (basename) part of a path, same as split(path)[1].
139  
140  -> def basename(p):
141         """Returns the final component of a pathname"""
142         p = os.fspath(p)
143         sep = _get_sep(p)
144         i = p.rfind(sep) + 1
145         return p[i:]

With Python 3.11:

$ python3.11 -m pdb repro2.py 
> /home/snoopjedi/repos/cpython/repro2.py(2)<module>()
-> import os.path
(Pdb) n
> /home/snoopjedi/repos/cpython/repro2.py(4)<module>()
-> os.path.basename("/foo/bar/baz.py")  # implemented in Python
(Pdb) s
--Call--
> <frozen posixpath>(140)basename()
(Pdb) l
[EOF]
(Pdb)

Pinging this issue per the devguide in the hopes of getting review on the PR, which has been open for a little while. I understand if things are too busy for review because of the release issues with 3.11, though!

This should mostly be resolved in 3.10. See issue gh-65935 (and PR gh-28656). We now set __file__ for frozen stdlib modules. Could you give it a try?

This should mostly be resolved in 3.10. See issue gh-65935 (and PR gh-28656). We now set __file__ for frozen stdlib modules. Could you give it a try?

I get the same behavior as in the initial report against the current tip of 3.10 (b60c3d2):

13:29 [snoopjedi@denton ~/repos/cpython (3.10)]
$ ./python -c "import sys; print(sys.version)"
3.10.5+ (remotes/upstream/3.10:b60c3d2f7e, Jul 21 2022, 12:34:09) [GCC 9.4.0]
13:29 [snoopjedi@denton ~/repos/cpython (3.10)]
$ ./python -m pdb repro.py 
> /home/snoopjedi/repos/cpython/repro.py(2)<module>()
-> import importlib._bootstrap
(Pdb) n
> /home/snoopjedi/repos/cpython/repro.py(5)<module>()
-> importlib._bootstrap._resolve_name("os", ".", 1)
(Pdb) s
--Call--
> <frozen importlib._bootstrap>(902)_resolve_name()
(Pdb) l
[EOF]

The __file__ attribute is reported correctly (I believe this has been the case since before I filed this ticket, actually), but pdb is relying on co_filename and #89815 still applies

Ah, thanks for checking. I missed that pdb wasn't using __file__. We should look at making sure co_filename is correct. I thought we were.

Yea, I'm not entirely sure what all goes into fixing the co_filename, but got the impression from your comment on that issue that it may be trickier than "just" patching the problem in pdb, hence this relatively unclever stopgap patch 😅

Yeah, it may be worth adding the stopgap fix in the meantime.

FYI I am looking into this. I'll probably make deepfreeze generate the correct co_filename but since this would have to be backported the stopgap solutions seems worth it. @ericsnowcurrently ?