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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
