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.
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
