[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Brett Cannon]

On Fri, 8 Apr 2016 at 09:05 Chris Barker <chris.barker at noaa.gov> wrote:

> On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 7 April 2016 at 03:26, Brett Cannon <brett at python.org> wrote:
>>
>
>
>> > Method or attribute? (changes what kind of one-liner you might use in
>> > libraries, but I think historically all protocols have been methods and
>> the
>> > serialized string representation might be costly to build)
>>
>
> couldn't it be a property?
>

A property is a method pretending to be an attribute, so yes. :)


>
>
>> Method, as long as there's a helper function somewhere
>
>
> what has the helper function got to do with whether it's a method or
> attribute (would we call a property an attribute here?)
>

Yes, a property is an attribute in this instance. And it somewhat tweaks
how simple of a one-liner is needed which in turn makes the function either
nearly redundant or helpful. With an attribute:

  getattr(path, '__ospath__', path)

With a method:

  path.__ospath__() if hasattr(path, '__ospath__') else path


>
> > Built-in? (name is dependent on #1 if we add one)
>>
>> os.fspath (alongside os.fsencode and os.fsdecode)
>>
>> (Putting this in a module low in the dependency stack makes it easy
>> for other modules to access without pulling in all of pathlib's
>> dependencies)
>
>
> Iike that -- though still =0.5 on having one at all -- this is only going
> to be used by the stdlib and other path-using libraries, not user code --
> is that that hard to call obj.__fspath__() ?
>

With a function we can add some type checking so that you know you are
getting back a string and not something else like an file descriptor int or
something.


>
> > Add the method/attribute to str? (I assume so, much like __index__() is
>> on
>> > int, but I have not seen it explicitly stated so I would rather clarify
>> it)
>>
>
> I thought the whole point off all this is that not any old string can be a
> path! (whereas any int can be an index). Unless we go with Chris A's
> suggestion that this be a more generic lossless string protocol, rather
> than just for paths.
>

The whole point is to not treat a path object like any old string. We still
have to support a string someone created that is a valid path. Remember,
what we're trying to avoid is people simply doing `str(path)` everywhere
since that works with e.g. None.


>
>
>> It's worth summarising in a PEP at least for communications purposes -
>> very easy for folks that don't follow python-dev to miss otherwise.
>>
>
> I'd say add it to the existing pathlib PEP -- along with the extra
> discussion of why Path does not inherit from str.
>

That's the plan.

-Brett


>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160408/1179cf1e/attachment.html>