[Python-ideas] Why was Path.path added?

Koos Zevenhoven k7hoven at gmail.com
Thu Apr 21 04:49:22 EDT 2016


On Thu, Apr 21, 2016 at 11:07 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 April 2016 at 07:38, Antony Lee <antony.lee at berkeley.edu> wrote:
>> Well, it's already there and it's probably too late to remove it, but
>
> pathlib is provisional, so it *can* be removed (and indeed probably
> will be - see the endless threads here and on python-dev)
>
>> introducing the idiom
>>
>> path_str = getattr(arg, "path", arg)
>>
>>
>> was not necessary: you could also write
>>
>> path_str = str(Path(arg))
>>
>>
>> which works just as well.
>
> The latter requires you to import pathlib, which is not Python
> 2.7-compatible. A minor point, but one reason why the path attribute
> offers simpler code. Also, str(Path(arg)) applies an unnecessary call
> to Path() if arg is already a path. (And str(arg) is not OK, as it
> will also accept things like ints).
>
> If you want the full details, please read the various threads that
> have been going on here for about a month. It isn't worth reiterating
> the debate again, I'm afraid - most people are fairly burned out on
> pathlib discussions by now.

The need for .path has been brought up before, although not because
.path was unnecessary, but because we wanted something better. And
this better thing currently goes by the name fspath, so instead of
str(Path(arg)) you should be calling os.fspath(arg), which even works
for third-party path libraries that implement the protocol. Regarding
this, however, we are seizing the discussions until we have a PEP.

A problem with .path, however, is that there should be only one way to
do it, and if I were to decide, I would probably remove it in
pathlib.PurePath before it's too late.

-Koos


More information about the Python-ideas mailing list