-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
GH-119668: expose importlib.machinery.NamespacePath #119669
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Misc/NEWS.d/next/Library/2024-05-28-17-14-30.gh-issue-119668.RrIGpn.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the comments that @picnixz left.
|
When you're done making the requested changes, leave the comment: |
Co-authored-by: Bénédikt Tran <[email protected]>
|
The docs failure is related to the fact that you did not yet merge main into your branch. Since I don't like updating branches of people, I'll let you do it yourself. |
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the previous review but I think the docs should explain the public API more in details and possibly have an example. I'm reviewing on my phone so sorry for the typos (and the lack of explicit suggestions)
|
|
||
| For top-level modules, the parent module's path is :data:`sys.path`. | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use .. versionadded:: next + what's new entry? While this only exposes a private class, I think users should be notified more than just with a blurb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe versionchanged? You can say something like, prior to 3.15, this class was exposed as the module private _NamespacePath class. With 3.15 and beyond, the class has been publicly exposed as NamespacePath.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The attribute is set on importlib._bootstrap_external, which is a private module, so I lean towards versionadded.
Lib/importlib/_bootstrap_external.py
Outdated
| self._path.append(item) | ||
|
|
||
|
|
||
| _NamespacePath = NamespacePath # for backwards compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make it a deprecated alias? (and emit a warning if we were to access the private name? that could help transition from the private to the public name).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who's the backwards-compatibility for? People poking at private attributes in private modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it hurts, but I also don't think it's necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... considering it has been designed to support backwards compatibility, I thought it was worth the deprecation warning so that we can eventually remove it. But that could make the code a bit more complex (as we would need some logic in the module's __getattr__), so I'm also fine with leaving it as is.
Doc/library/importlib.rst
Outdated
|
|
||
| It uses the module *name* to find its parent module, and from there it looks | ||
| up the parent's :attr:`module.__path__`. When this changes, the module's own | ||
| path is recomputed, using *path_finder*. The initial value is set to *path*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we perhaps mention the type of the path finder? (namely using some class Sphinx directive).
Btw, when you say that the initial value is set to path it seems that you are talking about the initial value of the path finder.
In addition, maybe mention that invalidating the caches forces the path to be recomputed (it might not necessarily be the case that the module parent's path has changed).
Finally, could you document the public methods of this new class? For instance there is no insert() method nor remove() as for lists.
I think an example of how to use it could be useful though I don't know whether we want to burden the docs even more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we perhaps mention the type of the path finder? (namely using some class Sphinx directive).
Btw, when you say that the initial value is set to path it seems that you are talking about the initial value of the path finder.
In addition, maybe mention that invalidating the caches forces the path to be recomputed (it might not necessarily be the case that the module parent's path has changed).
I've rewritten the docs to include this.
Finally, could you document the public methods of this new class? For instance there is no insert() method nor remove() as for lists.
Using NamespacePath's mutability at runtime is something that requires folks to be familiar with the source, so I don't think we really need to document that.
The main improvement I want to get from the PR is the ability to isinstance(path, NamespacePath) safely.
I think an example of how to use it could be useful though I don't know whether we want to burden the docs even more.
Similarly, I don't really think that is necessary given the advanced nature of the topic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really just a very minor doc change is needed to add a note as to when the class was publicly exposed.
Lib/importlib/_bootstrap_external.py
Outdated
| self._path.append(item) | ||
|
|
||
|
|
||
| _NamespacePath = NamespacePath # for backwards compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who's the backwards-compatibility for? People poking at private attributes in private modules?
|
|
||
| For top-level modules, the parent module's path is :data:`sys.path`. | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree.
Lib/importlib/_bootstrap_external.py
Outdated
| self._path.append(item) | ||
|
|
||
|
|
||
| _NamespacePath = NamespacePath # for backwards compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it hurts, but I also don't think it's necessary.
Co-authored-by: Brett Cannon <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, with some suggestions and comments. Thanks for finally fixing this wart!
Doc/library/importlib.rst
Outdated
| The *path* argument is the initial path value. | ||
|
|
||
| The *path_finder* argument is the callable used to recompute the path value. | ||
| It has the same signature as :meth:`MetaPathFinder.find_spec`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little hard to tell from context, but which "it" is "It" referring to? I'm not sure if this is part of the path_finder paragraph or a separate paragraph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It refers to path_finder, I'll rewrite it as "The callable has the same signature as (...)"
|
|
||
| For top-level modules, the parent module's path is :data:`sys.path`. | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe versionchanged? You can say something like, prior to 3.15, this class was exposed as the module private _NamespacePath class. With 3.15 and beyond, the class has been publicly exposed as NamespacePath.
Misc/NEWS.d/next/Library/2024-05-28-17-14-30.gh-issue-119668.RrIGpn.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Barry Warsaw <[email protected]>
Signed-off-by: Filipe Laíns <[email protected]>
_NamespacePath#119668