[Python-ideas] Dunder method to make object str-like

[Koos Zevenhoven]

I like this double-underscore path attribute better than my suggestion
almost two weeks ago in the other thread, but which did not get any
reactions:

On Sun, Mar 27, 2016 at 5:40 PM, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Sun, Mar 27, 2016 at 1:23 AM, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>>
>> I assume you meant to type pathlib.Path.path, so that Path("...").path ==
>> str(Path("...")). That's a good start, and I'm looking forward to Serhiy's
>> patch for making the stdlib accept Paths. But if Path will not subclass str,
>> we also need new stdlib functions that *return* Paths.
>
> Actually, now that .path is not out yet, would it make sense to call it
> Path.str or Path.strpath instead, and introduce the same thing on DirEntry
> and guarantee a str (instead of str or bytes as DirEntry.path now does)?
> Maybe that would lead to fewer broken implementations in third-party
> libraries too?

But maybe it could be called `__pathname__`, since 'names' are
commonly thought of as strings. This, implemented across the stdlib,
would obviously be better than the status quo.

Anyway, you are now discussing that remind me a lot of my thoughts
last week. I hope everyone realizes that, while this would still
require effort from the maintainers of every library that deals with
paths, this would not allow libraries to start returning pathlib
objects from functions without either breaking backwards compatibility
of their APIs or adding duplicate functions. We will end up with a
mess of some libraries accepting path objects and some not, and some
that screw up their DirEntry compatibility regarding bytestring paths
or that break their existing pure bytestring compatibility that they
didn't know of. All this could take a while and give people an
impression of inconsistency in Python.

-Koos