[Python-Dev] Defining a path protocol

[Gregory P. Smith]

Note: While I do not object to the bike shed colors being proposed, if you
call the attribute .__path__ that is somewhat confusing when thinking about
the import system which declares that *"any module that contains a __path__
attribute is considered a package"*.

So would module.__path__ become a Path instance in a potential future
making module.__path__.__path__ meaningfully confusing? ;)

I'm not worried about people who shove pathlib.Path instances in as values
into sys.modules and expect anything but pain. :P

__gps__



On Wed, Apr 6, 2016 at 3:46 PM Brett Cannon <brett at python.org> wrote:

> On Wed, 6 Apr 2016 at 15:22 Paul Moore <p.f.moore at gmail.com> wrote:
>
>> On 6 April 2016 at 20:39, Brett Cannon <brett at python.org> wrote:
>> >> I'm a little confused by this. To support the older pathlib, they have
>> >> to do patharg = str(patharg), because *none* of the proposed
>> >> attributes (path or __path__) will exist.
>> >>
>> >> The getattr trick is needed to support the *new* pathlib, when you
>> >> need a real string. Currently you need a string if you call stdlib
>> >> functions or builtins. If we fix the stdlib/builtins, the need goes
>> >> away for those cases, but remains if you need to call libraries that
>> >> *don't* support pathlib (os.path will likely be one of those) or do
>> >> direct string manipulation.
>> >>
>> >> In practice, I see the getattr trick as an "easy fix" for libraries
>> >> that want to add support but in a minimally-intrusive way. On that
>> >> basis, making the trick easy to use is important, which argues for an
>> >> attribute.
>> >
>> > So then where's the confusion? :) You seem to get the points. I
>> personally
>> > find `path.__path__() if hasattr(path, '__path__') else path` also
>> readable
>> > (if obviously a bit longer).
>>
>> The confusion is that you seem to be saying that people can use
>> getattr(path, '__path__', path) to support older versions of Python.
>> But the older versions are precisely the ones that don't have __path__
>> so you won't be supporting them.
>>
>
> Because pathlib is provisional the change will go into the next releases
> of Python 3.4, 3.5, and in 3.6 so new-old will have whatever we do. :) I
> think the key point is that this sort of thing will occur before you have
> access to some new built-in or something.
>
>
>>
>> >> >> >  3. Built-in? (name is dependent on #1 if we add one)
>> >> >>
>> >> >> fspath() -- and it would be handy to have a function that return
>> either
>> >> >> the __fspath__ results, or the string (if it was one), or raise an
>> >> >> exception if neither of the above work out.
>> >>
>> >> fspath regardless of the name chosen in #1 - a new builtin called path
>> >> just has too much likelihood of clashing with user code.
>> >>
>> >> But I'm not sure we need a builtin. I'm not at all clear how
>> >> frequently we expect user code to need to use this protocol. Users
>> >> can't use the builtin if they want to be backward compatible, But code
>> >> that doesn't need backward compatibility can probably just work with
>> >> pathlib (and the stdlib support for it) directly. For display, the
>> >> implicit conversion to str is fine. For "get me a string representing
>> >> the path", is the "path" attribute being abandoned in favour of this
>> >> special method?
>> >
>> > Yes.
>>
>> OK. So the idiom to get a string from a known Path object would be any of:
>>
>> 1. str(path)
>> 2. fspath(path)
>> 3. path.__path__()
>>
>> (1) is safe if you know you have a Path object, but could incorrectly
>> convert non-Path objects. (2) is safe in all cases. (3) is ugly. Did I
>> miss any options?
>>
>
> Other than path.__path__ being an attribute, nope.
>
>
>>
>> So I think we need a builtin.
>>
>
> Well, the ugliness shouldn't survive forever if the community shifts over
> to using pathlib while the built-in will. We also don't have a built-in for
> __index__() so it depends on whether we expect this sort of thing to be the
> purview of library authors or if normal people will be interacting with it
> (it's probably both during the transition, but I don't know afterwards).
>
>
>>
>> Code that needs to be backward compatible will still have to use
>> str(path), because neither the builtin nor the __path__ protocol will
>> exist in older versions of Python.
>
>
> str(path) will definitely work, path.__path__ will work if you're running
> the next set of bugfix releases. fspath(path) will only work in Python 3.6
> and newer.
>
>
>> Maybe a compatibility library could
>> add
>>
>> try:
>>     fspath
>> except NameError:
>>     try:
>>         import pathlib
>>         def fspath(p):
>>             if isinstance(p, pathlib.Path):
>>                 return str(p)
>>             return p
>>     except ImportError:
>>         def fspath(p):
>>             return p
>>
>> It's messy, like all compatibility code, but it allows code to use
>> fspath(p) in older versions.
>>
>
> I would tweak it to check for __fspath__ before it resorted to calling
> str(), but yes, that could be something people use.
>
>
>>
>> >> I'm inclined to think that if you are writing "pure
>> >> pathlib" code, pathobj.path looks more readable than fspath(pathobj) -
>> >> certainly no *less* readable.
>> >
>> > I don't' know what you mean by "pure pathlib". You mean code that only
>> works
>> > with pathlib objects? Or do you mean code that accepts pathlib objects
>> but
>> > uses strings internally?
>>
>> I mean code that knows it has a Path object to work with (and not a
>> string or anything else). But the point is moot if the path attribute
>> is going away.
>>
>> Other than to say that I do prefer the name "path", I just don't think
>> it's a reasonable name for a builtin. Even if it's OK for user
>> variables to have the same name as builtins, IDEs tend to colour
>> builtins differently, which is distracting. (Temporary variables named
>> "file" or "dir" are the ones I hit frequently...)
>>
>> If all we're debating is the name, though, I think we're pretty much
>> there :-)
>>
>
> It seems like __fspath__ may be leading as a name, but not that many
> people have spoken up. But that is not the only thing still up for debate.
> :)
>
> We have not settled on whether a built-in is necessary.  Maybe whatever
> function we come with should live in pathlib itself and not have it be a
> built-in?
>
> We have also not settled on whether __fspath__ should be a method or
> attribute as that changes the boilerplate one-liner people may use if a
> built-in isn't available. This is the first half of the protocol.
>
> What exactly should this helper function do? E.g. does it simply return
> its argument if __fspath__ isn't defined, or does it check for __fspath__,
> then if it's an instance of str, then TypeError? This is the second half of
> the protocol and will end up defining what a "path-like object" represents.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/4e143c34/attachment.html>