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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4