-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
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
_frozen_importlib should not have a __file__ attribute #65141
Comments
As part of the PEP-451 changes, frozen imports were updated to avoid setting the __file__ attribute, as that attribute makes no sense for frozen modules. However, _frozen_importlib isn't loaded through the normal mechanisms (they don't exist yet!), so it is still getting a __file__ attribute set. (This was discovered while investigating bpo-20884) This is a fairly harmless state of affairs, so I suggest we leave it alone in the 3.4 maintenance releases, and just tidy it up in 3.5. However, I'm also open to fixing it in 3.4.1. |
Here is a patch to change PyImport_ImportFrozenModuleObject() to not set __file__. Had to refactor some things as PyImport_ExecCodeModuleObject() was setting __file__ no matter what, so to avoid it even being used during import I had to change some things. |
Review posted. |
New version based on Eric's review. |
This patch can easily be incorporated into Python 3.4.1. It doesn't break backwards compatibility. |
It actually does break backwards-compatibility as an attribute will disappear on frozen modules for anyone who uses the imp API. While the chances of actually breaking someone's code is very small, there is still a chance. But I'm only -0 on backporting so other core devs could convince me that I'm being overly cautious. |
I would say go for it. I don't think anyone's code would break. Anyway, if people see that something in the new version of Python breaks their code, they down-grade; otherwise they read the changelog and fix their code accordingly. So no worries here. :) |
Latest patch LGTM. |
As I've thought about it, I've gone from -0 to +1 on applying this to both 3.4 and 3.5. The bug and fix should impact very little* code. In fact, I doubt anyone would have noticed if Nick hadn't. :) It would be nice to have this right in 3.4.
|
I'm setting Python 3.4 to also be affected by this issue. Thank you, Brett, for making the patch. I hope this gets commited soon. |
Yeah, as noted in my original comment, +0 for "it's just a bug" from me, as it was a quirk of the way this particular frozen module is initialised. |
Haven't we forget something in the patch for the docs? + .. versionchanged:: 3.5
Where's 3.4 mentioned? Should we add the mention? Like... |
No one interested in fixing this anymore, despite the patch and all? |
My Python free time is on Fridays, which is when I plan to make a final call and either apply to Python 3.4 and 3.5 or just Python 3.5. |
New changeset fef890bd60b1 by Brett Cannon in branch '3.4': New changeset a11ec7aaac10 by Brett Cannon in branch 'default': |
Import "_frozen_importlib" could not be resolved please help me |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: