[Python-ideas] tweaking the file system path protocol

Wolfgang Maier wolfgang.maier at biologie.uni-freiburg.de
Sun May 28 17:33:30 EDT 2017

On 28.05.2017 18:32, Steven D'Aprano wrote:
> On Sun, May 28, 2017 at 05:35:38PM +0300, Koos Zevenhoven wrote:
>> Don't get me wrong, I like consistency very much. But regarding the
>> __fspath__ case, there are not that many people *writing*
>> fspath-enabled classes. Instead, there are many many many more people
>> *using* such classes (and dealing with their compatibility issues in
>> different ways).
> What sort of compatibility issues are you referring to? os.fspath is new
> in 3.6, and 3.7 isn't out yet, so I'm having trouble understanding what
> compatibility issues you mean.

As far as I'm aware the only such issue people had was with building 
interfaces that could deal with regular strings and pathlib.Path 
(introduced in 3.4 if I remember correctly) instances alike. Because 
calling str on a pathlib.Path instance returns the path as a regular 
string it looked like it could become a (bad) habit to just always call 
str on any received object for "compatibility" with both types of path 
representations. The path protocol is a response to this that provides 
an explicit and safe alternative.

>> For those people, the current behavior brings consistency
> That's a very unintuitive statement. How is it consistent for fspath to
> call the __fspath__ dunder method for some objects but ignore it for
> others?

The path protocol brings a standard way of dealing with diverse path 
representations, but only if you use it. If people keep using 
str(path_object) as before, then they are doing things wrongly and are 
no better or safer off than they were before! The path protocol does 
*not* use __fspath__ as an indicator that an object's str-representation 
is intended to be used as a path. If you had wanted this, the PEP should 
have defined __fspath__ not as a method, but as a flag and have the 
protocol check that flag, then call __str__ if appropriate.
With __fspath__ being a method that can return whatever its author sees 
fit, calling str to get a path from an arbitrary object is just as wrong 
as it always was - it will work for pathlib.Path objects and might or 
might not work for some other types. Importantly, this has nothing to do 
with this proposal, but is in the nature of the protocol as it is 
defined *now*.

>> ---after all, it was of course designed by thinking about
>> it from all angles and not just based on my or anyone else's own use
>> cases only.
> Can explain the reasoning to us? I don't think it is explained in the
> PEP.

More information about the Python-ideas mailing list