[Python-Dev] file system path protocol PEP (original) (raw)
Sven R. Kunze srkunze at mail.de
Fri May 13 12:06:17 EDT 2016
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]