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