Feature or enhancement

This enhancement proposes that we allow state to be shared between related instances of subclasses ofpathlib.PurePath andpathlib.Path.

Pitch

Now that#68320 is resolved, users can subclasspathlib.PurePath andpathlib.Path directly:

importpathlibclassMyPath(pathlib.Path):defmy_custom_method(self):passetc=MyPath('/etc')etc_hosts=etc/'hosts'etc_hosts.my_custom_method()

However, some user implementations of classes - such asTarPath orS3Path - would require underlyingtarfile.TarFile orbotocore.Resource objects to be shared between path objects (etc andetc_hosts in the example above). Such sharing of resources is presently rather difficult, as there's no single instance method used to derive new path objects.

This feature request proposes that we add a newPurePath.makepath() method, which is called whenever one path object is derived from another, such as injoinpath(),iterdir(), etc. The default implementation of this method looks something like:

defmakepath(self,*args):returntype(self)(*args)

Users may redefine this method in a subclass, in conjunction with a customized initializer:

classSessionPath(pathlib.Path):def__init__(self,*args,session_id):super().__init__(*args)self.session_id=session_iddefmakepath(self,*args):returntype(self)(*args,session_id=self.session_id)etc=SessionPath('/etc',session_id=42)etc_hosts=etc/'hosts'print(etc_hosts.session_id)# 42

I propose the name "makepath" for this method due to its close relationship with the existing "joinpath" method:a.joinpath(b) == a.makepath(a, b).

Performance

edit: this change has been taken care of elsewhere, and so implementing this feature request should no longer have much affect on performance.

This change will affect the performance of some pathlib operations, because it requires us to remove the_from_parsed_parts() constructor, which is an internal optimization used in cases where path parsing and normalization can be skipped (for example, in theparents sequence). I suggest that, within the standard library, pathlib is not a particularly performance-sensitive module -- few folks reach to pathlib for reason of speed. Within pathlib itself, the savings from optimizing these "pure" methods are usually drowned out by the I/O costs of "impure" methods. With the appeal of this feature in mind, I believe the performance cost is justified.

However, if the performance degradation is considered unacceptable, there's a possible alternative: add anormalize keyword argument to the path initializer and tomakepath(). This would require some serious internal surgery to make work, and might be difficult to communicate to users, so at this stage it's not my preferred route forward.

Previous discussion

https://discuss.python.org/t/make-pathlib-extensible/3428/47 (and replies)

Linked PRs

• GH-100479: Add optionalblueprint argument topathlib.PurePath #100481
• GH-100479: Addpathlib.PurePath.with_segments() #103975
• GH-100479: Fix pathlib test failure on WASI #104215