Home Original page

[Python-Dev] file system path protocol PEP

Sven R. Kunze srkunze at mail.de
Fri May 13 12:06:17 EDT 2016 
On 13.05.2016 11:48, Koos Zevenhoven wrote:
> This issue is coupled with the future optimization questions.

AFAIC coupling API design to optimization is called premature optimization.

>> 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.

> I do think the documentation of the protocol should say that str or
> bytes subclasses should not implement __fspath__.

Indeed. Just one minor note here: str or bytes subclasses *can* 
implement __fspath__ and currently it will be *ignored*. Maybe that 
changes in the future. So, that's the reason it should not be implemented.

> So no API inconsistency there.

API consistency is not defined by docs-matching-implementation but by 
implementation-matching-expectations.


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160513/e93219dc/attachment.html>
More information about the Python-Dev mailing list