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~