The documentation states that a __loader__ of a namespace package should be None:
1 "For namespace packages this should be set to None."
2 "To indicate to the import machinery that the spec represents a namespace portion. the path entry finder sets “loader” on the spec to 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: #10016
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 _bootstrap.ModuleSpec.loader attribute of a namespace package remains None until the call to the importlib._bootstrap._init_module_attrs function): #10376
@barry, you started a review of PR10016 and I believe all your requested changes have been made, so please review again when you get a chance. Please also take a look at PR10376. Thanks!
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.
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.
I haven't merged PR 10016, but I left some additional comments. Are you still interested in shepherding this PR?
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.
Activity
JulienPalard commented on Nov 6, 2018
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 ?).
maggyero commented on Nov 7, 2018
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:
#10016
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 _bootstrap.ModuleSpec.loader attribute of a namespace package remains None until the call to the importlib._bootstrap._init_module_attrs function):
#10376
csabella commented on Apr 9, 2019
@barry, you started a review of PR10016 and I believe all your requested changes have been made, so please review again when you get a chance. Please also take a look at PR10376. Thanks!
warsaw commented on May 1, 2019
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.
maggyero commented on Jun 23, 2019
@julien, @barry
Now that the PRs are merged, I think that we can close this issue.
maggyero commented on Jun 23, 2019
Oops, sorry, only one of the two PRs has been merged.
warsaw commented on Oct 21, 2020
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.
miss-islington commented on Oct 21, 2020
New changeset 27f1bd8 by Géry Ogam in branch 'master':
bpo-35181: Correct importlib documentation for some module attributes (GH-15190)
27f1bd8
miss-islington commented on Oct 21, 2020
New changeset 916ac95 by Miss Skeleton (bot) in branch '3.8':
bpo-35181: Correct importlib documentation for some module attributes (GH-15190)
916ac95
miss-islington commented on Oct 21, 2020
New changeset 6e842bc by Miss Skeleton (bot) in branch '3.9':
bpo-35181: Correct importlib documentation for some module attributes (GH-15190)
6e842bc
warsaw commented on Oct 21, 2020
@maggyero - I haven't merged PR 10016, but I left some additional comments. Are you still interested in shepherding this PR?
maggyero commented on Oct 24, 2020
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.
warsaw commented on Apr 27, 2022
#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.