-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Doc: Namespace Packages: Inconsistent documentation of __loader__ being None #79362
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
Comments
The documentation states that a __loader__ of a namespace package should be None:
But this looks wrong 3, looks like it has been changed in 4/5. I think one should rely on __file__ being None on namespace packages (which make sense as they span over multiple directories) instead of __loader__ being None (a side effect of the import machinery ?). |
It looks like Barry Warsaw has not been fully updated the documentation after making the __spec__.loader attribute match with the __loader__ attribute, and the __spec__.file attribute match with the __file__ attribute for namespace packages. Here is a pull request to update the library documentation of importlib (your first link [1]) with the current Barry's implementation: Here is another pull request to update the reference documentation of the import system (your second link [2], but for a different paragraph, as I think the "To indicate to the import machinery that the spec represents a namespace portion the path entry finder sets “loader” on the spec to None" sentence is correct, since the |
I've approved both PRs, however I am rather uncomfortable about the code snippet in import.rst. Géry's change is a good one AFAICT, and thanks for the contribution! I would feel much better about the long term correctness of this code snippet if we had a doctest to run over it. But that's for another time. |
Oops, sorry, only one of the two PRs has been merged. |
Apologies for the long delay in reviewing this bug. I'm looking at it now, however since Python 3.7 is in security-only mode, this will only apply to 3.10, 3.9, and 3.8. |
@maggyero - I haven't merged PR 10016, but I left some additional comments. Are you still interested in shepherding this PR? |
Thanks @barry for reviewing and merging PR 15190
Also thanks for helping me with @ericsnowcurrently advancing this last PR. Yes I am still interested, I have reviewed all the comments and updated the whole thing, doing my best to keep the two descriptions of the module attributes and spec attributes consistent since this PEP updates both descriptions. |
#15190 has been merged, so I believe all issues mentioned in this issue have been resolved. The issue just never got closed, so closing it now. Please follow up here or open a new issue and @ mention me if anyone thinks otherwise. Thanks for all the contributions. |
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: