[Tim] >> I think it needs more words, though, to flesh out what about this is >> allowed by the language (as opposed to what CPython happens to do), >> and to get closer to what Guido is trying to get at with his >> "*implicit* calls". For example, it's at work here, but there's not a >> built-in container in sight: >> >> >>> import math >> >>> def f(): >> ... while True: >> ... yield math.nan >> >>> math.nan in f() >> True
[Serhiy Storchaka <[email protected]>] > It is documented in: > https://docs.python.org/3/reference/expressions.html#membership-test-operations > > """ > For user-defined classes which do not define :meth:`__contains__` but do > define > :meth:`__iter__`, ``x in y`` is ``True`` if some value ``z``, for which the > expression ``x is z or x == z`` is true, is produced while iterating > over ``y``. > ... But _should_ it be? There are two parts to that: 1. Consensus seems to be that whether - and where - implicit equality comparisons exploit object identity should be implementation-defined. If so, the quoted docs are over-specified, elevating a CPython implementation choice to a language requirement. 2. As I said in the first message, consequences of this choice are "all over the place". Repeating equivalents of "x is z or x == z" all over the docs is ugly and error-prone, and especially if it also needs to spell out that the "x is z" part is something CPython does but that other implementations may not do. _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QLBATZTQQU5H4BGJAFRO3DNXN23NB7UU/ Code of Conduct: http://python.org/psf/codeofconduct/
