Skip to content
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-40350: fix namespace package support in modulefinder #29196

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

FFY00
Copy link
Member

@FFY00 FFY00 commented Oct 23, 2021

Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00
Copy link
Member Author

FFY00 commented Oct 23, 2021

__file__ is not set anymore. I don't know exactly which part of the code is responsible for that. Should we keep setting __file__, or is leaving it out fine?

Signed-off-by: Filipe Laíns <lains@riseup.net>
# See # https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module
# and bpo-32305
module.__file__ = None
if _bootstrap_external and isinstance(loader, _bootstrap_external.NamespaceLoader):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rescoping this change means it no longer falls under "A backward compatibility hack." Is that intentional?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the if loader is None block above still needed now that spec.loader is set in _bootstrap_external?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did do a deep dive into this and was meaning to write a more in-depth explanation. If I understand correctly, the backwards compatibility hack is instantiating the loader, not setting __file__. This function is meant to fill these missing attributes, but up until now it always expected to be the one instantiating the loader on namespace packages, which now changed with this PR. This should also trip up on 3rd party finders that set the loader for namespace packages, but so far no one has reported it yet.

# this is the best place to ensure this consistency.
#
# See # https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module
# and bpo-32305
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this comment should now also mention bpo-40350.

@@ -17,6 +17,7 @@
_PKG_DIRECTORY = 5
_C_BUILTIN = 6
_PY_FROZEN = 7
_NAMESPACE = 8
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change feels wrong based on the comment above ("Old imp constants"), because it introduces a "new old constant". Perhaps the comment just needs to be replaced with something more accurate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I share the same concern, but these constants are being used here to identify the module type, so maybe we can change the comment to "constants initially imported from imp module" or something similar.

@jaraco
Copy link
Member

jaraco commented Oct 31, 2021

I see tests are failing. I suspect that's because the change modifies bootstrap_external but the C version hasn't been regenerated from it. I believe you need to run make regen-importlib to regenerate the C version of that module. It's been a while, so I only have 50% confidence in my understanding.

Edit: I ran make regen-importlib and nothing changed, so I guess that step isn't needed. I guess the test failures are actual test failures needing investigation.

@FFY00
Copy link
Member Author

FFY00 commented Oct 31, 2021

I am not home now, so I will finish up looking into the feedback later.

@github-actions
Copy link

github-actions bot commented Dec 1, 2021

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Dec 1, 2021
@Tayodele
Copy link

Any progress on this PR? I have run into the same issue and was wondering if this fix was coming anytime soon. I can take a look but I have never contributed so I don't really know how that works with a PR I didn't make myself.

@FFY00
Copy link
Member Author

FFY00 commented Apr 13, 2022

I will try to rebase the PR and fix the tests in the weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review stale Stale PR or inactive for long period of time.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants