[Python-Dev] file system path protocol PEP

[Ethan Furman]

On 05/13/2016 09:06 AM, Sven R. Kunze wrote:
> On 13.05.2016 11:48, Koos Zevenhoven wrote:
 >> Sven R Kunze had previously queried:

>>> However, the proposed semantics will change if the checks are swapped. So,
>>> my actual question is:
>>>
>>> Is that an intended API inconsistency or a known bug supposed to be resolved
>>> later?
>>
>> Taking into account the description (and the drafted type hint), which
>> the documentation will probably reflect, the semantic effects of that
>> are very minor or nonexistent.
>
> From your perspective. As far as I remember, one goal of this proposal
> was to avoid wallet gardens. During the lengthy discussion on
> python-ideas people brought up that some third-party libs indeed
> subclass from str. They are currently locked out.

Two points:

1) What is a wallet garden?

2) If a third-party path lib subclasses either str or bytes, and the 
os.* and other stdlib functions accept str or bytes, how are they locked 
out by not having an __fspath__?

Assuming, of course, that those functions use isinstance and not type 
(if do use type a bug should be filed against them.

> Indeed. Just one minor note here: str or bytes subclasses *can*
> implement __fspath__ and currently it will be *ignored*.

Sure.  And int subclasses can implement __index__, which will likewise 
be ignored.

>> So no API inconsistency there.
>
> API consistency is not defined by docs-matching-implementation but by
> implementation-matching-expectations.

Well, probably both.  ;)

--
~Ethan~