-
-
Notifications
You must be signed in to change notification settings - Fork 32k
bpo-21736: Set __file__ on frozen stdlib modules. #28656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-21736: Set __file__ on frozen stdlib modules. #28656
Conversation
a1cc171
to
36112c1
Compare
🤖 New build scheduled with the buildbot fleet by @ericsnowcurrently for commit 36112c1ec211049084cdc2b5010c11c08939ac28 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
7934888
to
1d6ff36
Compare
🤖 New build scheduled with the buildbot fleet by @ericsnowcurrently for commit 1d6ff3632519080ca20b69832545ec0ba1496af5 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
1d6ff36
to
d8e19e0
Compare
🤖 New build scheduled with the buildbot fleet by @ericsnowcurrently for commit 79c1035 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
c9a77db
to
9687202
Compare
This appears to have caused https://bugs.python.org/issue45506 - out of tree builds can't pass several tests. |
Currently frozen modules do not have
__file__
set. In their spec,origin
is set to "frozen" and they are marked as not having a location. (Similarly, for frozen packages__path__
is set to an empty list.) However, for frozen stdlib modules we are able to extrapolate__file__
as long as we can determine the stdlib directory at runtime. (We now do so since gh-28586.) Having__file__
set is helpful for a number of reasons. Likewise, having a non-empty__path__
means we can import submodules of a frozen package from the filesystem (e.g. we could partially freeze theencodings
module).This change sets
__file__
(and adds to__path__
) for frozen stdlib modules. It usessys._stdlibdir
(from gh-28586) and the frozen module alias information (from gh-28655). All that work is done inFrozenImporter
(inLib/importlib/_bootstrap.py
). Also, if a frozen module is imported before importlib is bootstrapped (during interpreter initialization) then we fix up that module and its spec during the importlib bootstrapping step (i.e.imporlib._bootstrap._setup()
) to match what gets set byFrozenImporter
, including setting the file info (if the stdlib dir is known). To facilitate this, modules imported usingPyImport_ImportFrozenModule()
have__origname__
set using the frozen module alias info.__origname__
is popped off during importlib bootstrap.(To be clear, even with this PR the new code to set
__file__
during fixups inimporlib._bootstrap._setup()
doesn't actually get triggered yet. This is becausesys._stdlibdir
hasn't been set yet in interpreter initialization at the point importlib is bootstrapped. However, we do fix up such modules at that point to otherwise match the result of importing throughFrozenImporter
, just not the__file__
and__path__
parts. Doing so will require changes in the order in which things happen during interpreter initialization. That can be addressed separately. Once it is, the file-related fixup code from this PR will kick in.)Here are things this PR does not do:
__file__
for non-stdlib modules (no way of knowing the parent dir)__file__
if the stdlib dir is not known (nor assume the expense of finding it)__file__
if the stdlib is in a zip file__file__
actually exists (too expensive)__path__
for frozen packages that alias a non-package (since there is no package dir)Other things this PR skips, but we may do later:
__file__
on modules imported usingPyImport_ImportFrozenModule()
co_filename
when we unmarshal the frozen code object while importing the module (e.g. inFrozenImporter.exec_module()
) -- this would allow tracebacks to show source linesFrozenImporter.get_filename()
andFrozenImporter.get_source()
https://bugs.python.org/issue21736