Skip to content

bpo-37800: Clean up importlib documentation for some module attributes #10016

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

Merged
merged 48 commits into from
Nov 16, 2021

Conversation

geryogam
Copy link
Contributor

@geryogam geryogam commented Oct 20, 2018

https://bugs.python.org/issue37800

Automerge-Triggered-By: GH:brettcannon

* The ``loader`` attribute is not `None` for namespace packages (see https://stackoverflow.com/questions/52869541/namespace-package-loader-attribute-not-set-to-none).
* The ``submodule_search_locations `` attribute is not `None` for non-package modules, it is not set (see https://docs.python.org/3/reference/import.html#__path__).
* The ``cached `` attribute is not sometimes `None`, it is sometimes not set (see https://docs.python.org/3/reference/import.html#__cached__).
* The ``parent `` attribute is not `None` but the empty string for non-package top-level modules (see https://docs.python.org/3/reference/import.html#__package__).
@orlnub123
Copy link
Contributor

orlnub123 commented Oct 21, 2018

There seems to be some misconceptions here, a ModuleSpec object is different from the attributes set on modules. Those attributes do get set (or not set) based on the ModuleSpec object but the docs aren't referring to them.

I think the confusion aroused from the format in which the docs present this information. The module's attributes don't exactly reflect the ModuleSpecs' from which they originate from as you've said, yet the docs act like they do. If there is a change to be had, I'd suggest clarifying that they aren't always equal or, if the behavior of __loader__ for namespace packages changes, that they aren't always defined.

@geryogam
Copy link
Contributor Author

geryogam commented Oct 21, 2018

@orlnub123 I disagree here. The values of the attributes of a module and the attributes of its __spec__ attribute are equivalent, it is just that there are not synchronized, as the documentation already states clearly:

Note however that while the values are usually equivalent, they can differ since there is no synchronization between the two objects. Thus it is possible to update the module’s __path__ at runtime, and this will not be automatically reflected in __spec__.submodule_search_locations.

Try to import a namespace package and you will see that both package.__spec__.loader and package.__loader__ attributes are not None, contrary to what the documentation states.

And you can verify my three other claims as well.

@orlnub123
Copy link
Contributor

My bad, I didn't know the spec's loader got mutated which is a bit intriguing to be honest. I do agree that they are equivalent after learning about that, guess I had some misconceptions of my own.

I still do think there is some confusion. Where the docs state that they can be set to None, it's referring to the attributes on the spec. For example if the spec sets submodule_search_locations to None, the corresponding module's __path__ attribute doesn't get defined. That doesn't mean you can return a spec which doesn't have a submodule_search_locations attribute defined, that would lead to an error.

One thing I did notice that is indeed wrong is that the ModuleSpec's parent attribute never returns None. According to PEP 366 setting it to None is fine, as the import system corrects it later on. This makes me question whether the docs are there to help you create your own arbitrary spec object, or to specifically document the ModuleSpec.

@geryogam
Copy link
Contributor Author

geryogam commented Oct 21, 2018

@orlnub123 My bad too, my claims for the submodule_search_locations and the cached attributes were wrong. I only checked the representation of the module.__spec__ attribute, which does not display its None attributes, so I thought there were not set, but calling explicitly module.__spec__. submodule_search_locations and module.__spec__.cached does yield None (not an AttributeError). I have updated the pull request and its description accordingly.
My other claims for the loader and the parent attributes still hold true.

@geryogam geryogam changed the title Correct the description of ModuleSpec attributes Correct the description of the ModuleSpec attributes Oct 21, 2018
@orlnub123
Copy link
Contributor

The loader attribute is a bit of an edge case. You would initially set it to None when creating the spec for namespace packages as talked about in PEP 451, but it would then get mutated to a non-none value after module creation. I don't think removing any mention about this would be a good idea.

@geryogam
Copy link
Contributor Author

geryogam commented Oct 21, 2018

@orlnub123 Thank you for the PEP reference. I have just emailed the author Eric Snow so that he could give us his thought.

@geryogam geryogam changed the title Correct the description of the ModuleSpec attributes bpo-35181: Correct the description of the ModuleSpec attributes Nov 7, 2018
@geryogam geryogam changed the title bpo-35181: Correct the description of the ModuleSpec attributes bpo-35181: Correct the description of the _bootstrap.ModuleSpec attributes Nov 7, 2018
@geryogam geryogam changed the title bpo-35181: Correct the description of the _bootstrap.ModuleSpec attributes bpo-35181: Correct the description of ModuleSpec attributes Nov 7, 2018
Copy link
Member

@warsaw warsaw left a comment

Choose a reason for hiding this comment

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

Thanks for helping to improve the documentation. I like your changes, although I have a few grammatical suggestions.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@geryogam
Copy link
Contributor Author

@warsaw Thank you for the review. I have updated the pull request.

@csabella csabella requested review from warsaw and brettcannon April 9, 2019 22:54
@brettcannon
Copy link
Member

@warsaw are you available to review again?

@brettcannon
Copy link
Member

While we wait to hear back from @warsaw , one comment I have is there seems to be a loss of detail on the ModuleSpec docs but an increase on the load_module() docs which is actually the reverse of how I would expect it to go (especially since load_module() is deprecated).

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@ericsnowcurrently
Copy link
Member

If you are still interested in seeing this PR merged, please let me know. Otherwise I am fine with closing it.

Yeah, this is worth following through. Sorry it's dragged on so long. I'm going to prioritize getting this wrapped up ASAP.

@geryogam
Copy link
Contributor Author

I have made the requested changes; please review again.

If you are still interested in seeing this PR merged, please let me know. Otherwise I am fine with closing it.

Yeah, this is worth following through. Sorry it's dragged on so long. I'm going to prioritize getting this wrapped up ASAP.

Thanks for looking at this @ericsnowcurrently! I have applied all your suggestions.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@ericsnowcurrently, @brettcannon, @warsaw, @JulienPalard: please review the changes made to this pull request.

@brettcannon
Copy link
Member

@ericsnowcurrently can you have a look?

@ericsnowcurrently
Copy link
Member

Yeah, sorry, today or tomorrow.

Copy link
Member

@ericsnowcurrently ericsnowcurrently left a comment

Choose a reason for hiding this comment

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

This looks good. Thanks so much for your patience, thoughtfulness, and diligence!!!

I've left a few comments, one of which is a minor nit, one is a potentially incorrect (or confusing) phrase, and the last is just a reminder (with nothing to change). I'm approving the PR under the assumption that you will make any necessary corrections before this gets merged (in case I'm not the one to merge it).

Thanks again!

@miss-islington
Copy link
Contributor

@maggyero: Status check is done, and it's a success ✅ .

@miss-islington miss-islington merged commit d7e2100 into python:main Nov 16, 2021
@geryogam geryogam deleted the patch-1 branch November 16, 2021 20:02
@geryogam
Copy link
Contributor Author

@brettcannon Thanks for helping us complete this PR! @ericsnowcurrently Thanks for your multiple careful reviews! And thanks to the other reviewers.

@ericsnowcurrently
Copy link
Member

Thanks for your patience, @maggyero! Congrats on getting this merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.