| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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 path.parents, path.iterdir()). I'd love to be able to convince you this is a good idea! |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
Well, it's undocumented and underscore-prefixed. We've been breaking other things like that over the last few months, e.g. removing Path._accessor. It's hard to make progress without doing this. |
Sorry, something went wrong.
Okay, I chatted with Brandt at the sprint, and he persuaded me that I was worrying too much about this hypothetical scenario :) |
Sorry, something went wrong.
|
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 :) |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
There was a problem hiding this comment.
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 :)
Sorry, something went wrong.
|
Thanks so much for the thorough review! I'll open a thread about the method name shortly. |
Sorry, something went wrong.
There was a problem hiding this comment.
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!
Sorry, something went wrong.
|
Yeah, I was missing the wood for the trees there. Massive improvement. |
Sorry, something went wrong.
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
There was a problem hiding this comment.
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 :)
Sorry, something went wrong.
| 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.
Should we add a test to make sure diamond inheritance works?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
Perhaps a hidden .. doctest:: block would be best?
Sorry, something went wrong.
| 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.
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
Sorry, something went wrong.
|
I've created a branch/PR that uses a __newpath__() method, for comparison's sake: |
Sorry, something went wrong.
|
Closing in favour of #103975. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Add optional blueprint argument to pathlib.PurePath and Path. This argument is supplied whenever a derivative path is created, such as from PurePath.parent. Subclasses may use this to pass information between paths.