-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
GH-100479: Add optional blueprint
argument to pathlib.PurePath
#100481
Conversation
pathlib.PurePath.makepath()
; unify path object constructionpathlib.PurePath.makepath()
; unify path object construction
Hey @serhiy-storchaka, I believe you're pretty familiar with the pathlib internals. Penny for your initial impressions of this patch? It does cut out a key part of the initial pathlib design: the idea of skipping re-parsing and re-normalizing paths in case where we can be sure it's not necessary (e.g. in |
19bf6ff
to
99eb8b1
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
pathlib.PurePath.makepath()
; unify path object constructionpathlib.PurePath.makepath()
This is now ready for review! My previous comment no longer applies, as we fixed the pathlib construction weirdness in #102789. This change should be pretty performance-neutral now. |
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.
After looking through the changes, this is an obvious approve from my side: the changes make a lot sense and we have been waiting for them for a long time.
My biggest concern is that we're adding a breaking change to _from_parsed_parts
which is not a big problem on its own because the interface is private, but I would still take a look around for some relatively popular libraries that might actually be dependent on that interface.
Well, it's undocumented and underscore-prefixed. We've been breaking other things like that over the last few months, e.g. removing |
Okay, I chatted with Brandt at the sprint, and he persuaded me that I was worrying too much about this hypothetical scenario :) |
FWIW, I am open to alternatives to this new method. There are things we can do like pass an opaque object around, or derive a new type to 'bind' the context. I went back and forth with these, and in the end went with this approach as it appears to be the simplest. But happy to look again if you have suggestions :) |
Also as a bit of a testimonial I really like the design and have the changes for something I locally implemented for this PR and it makes my code significantly nicer |
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 implementation and the docs here look great. Thanks for addressing my concerns, and for your patience :)
My only remaining reservation is about the name of the method itself. I think I would still prefer "newpath" -- but if you'd like more opinions, you could always start a thread on Discourse or Discord :)
Thanks so much for the thorough review! I'll open a thread about the method name shortly. |
pathlib.PurePath.makepath()
template
argument to pathlib.PurePath
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.
Wow, using the template
argument instead of adding the makepath
method makes it so much easier for me to understand what's going on! This is a great improvement!
Misc/NEWS.d/next/Library/2023-04-03-22-02-35.gh-issue-100479.kNBjQm.rst
Outdated
Show resolved
Hide resolved
Yeah, I was missing the wood for the trees there. Massive improvement. |
Co-authored-by: Alex Waygood <[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.
LGTM. I guess the only remaining question is whether "template" is the best name for this new parameter. I'm fine with "template", but you might want to head back to Discourse if you want some more bikeshedding :)
Doc/library/pathlib.rst
Outdated
@@ -159,7 +159,7 @@ we also call *flavours*: | |||
|
|||
class MyPath(PurePosixPath): | |||
def __init__(self, *pathsegments, template=None, session_id=None): | |||
super().__init__(*pathsegments) | |||
super().__init__(*pathsegments, template=template) |
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 add a test to make sure diamond inheritance works?
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'm not sure. There's only one place in pathlib.py
where we call super()
, and that only exists because we need to raise a deprecation warning when additional arguments are supplied to pathlib.Path()
. The Path.__init__()
method will be removed in 3.14, at which point it will be impossible for the test to fail.
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.
Perhaps a hidden .. doctest::
block would be best?
Doc/library/pathlib.rst
Outdated
The optional *template* argument may provide another path object. It is | ||
supplied whenever a new path object is created from an existing one, such | ||
as in :attr:`parent` or :meth:`relative_to`. Subclasses may use this to | ||
pass information between path objects. For example:: |
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.
Does it make sense to specify that template: Self | None
here? I.e. that if template is not None, it will be an instance of the current (user-defined) class.
A
template
argument to pathlib.PurePath
blueprint
argument to pathlib.PurePath
I've created a branch/PR that uses a |
blueprint
argument to pathlib.PurePath
blueprint
argument to pathlib.PurePath
Closing in favour of #103975. |
Add optional blueprint argument to
pathlib.PurePath
andPath
. This argument is supplied whenever a derivative path is created, such as fromPurePath.parent
. Subclasses may use this to pass information between paths.