[Python-Dev] When should pathlib stop being provisional?

Ethan Furman ethan at stoneleaf.us
Wed Apr 6 11:01:30 EDT 2016

On 04/06/2016 02:50 AM, Antoine Pitrou wrote:
> Ethan Furman <ethan <at> stoneleaf.us> writes:
>>> Not sure about os.path.*. The purpose of os.path module is manipulating
>>> string paths. From the perspective of pathlib it can look lower level.
>> The point is that a function that receives a "path" object (whether str
>> or Path) shouldn't have to care: it should be able to call os.path.split
>> on the thing it received and get back a usable answer.
> pathlib should already replicate the useful parts of os.path.  That was
> the design goal after all.

Yes it does, and very well.

> So this is like saying you want a Python file or socket object to be
> accepted by os.read(). In the rare case where you want that, you call the
> .fileno() method explicitly. The equivalent for Path objects is to
> lookup the .path attribute explicitly.

Unfortunately for Path objects there is already a well-established 
ecosystem for dealing with paths as strings, and it currently breaks 
when passed a Path path object.  This is a high barrier to entry. 
Having the stdlib support Path objects would lower that barrier 


More information about the Python-Dev mailing list