Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
I've submitted a PR for this. I did discover a use case for boolean evaluation
while doing this in the functools.total_ordering helpers. While it's
legitimate, it *looks* wrong (the code looks like it didn't consider the
possibility of NotImplemented even though it did), and really only applies to
the case total_ordering handles on behalf of most folks (implementing one
comparator in terms of two others).
The specific case was:
def _le_from_lt(self, other, NotImplemented=NotImplemented):
'Return a <= b. Computed by @total_ordering from (a < b) or (a == b).'
op_result = self.__lt__(other)
return op_result or self == other
(with a similar implementation for _ge_from_gt). It happens to work because the
return value of __lt__ is used directly for both True and NotImplemented cases,
with only False delegating to equality. It's not at all clear that that's
correct at first glance though, and the fix to avoid the warning is simple,
matching the other 10 comparator helpers by explicit checking for
NotImplemented via:
if op_result is NotImplemented:
return NotImplemented
That's about the strongest case I can find for "legitimate" use of
NotImplemented in a boolean context, so I figured I'd point it out explicitly
so people knew it existed.
If that makes an eventual TypeError a non-starter, I'd still like that usage to
emit a warning (e.g. a RuntimeWarning) simply because the utility of that one
little shortcut pales in comparison to the damage done by the *many* misuses
that occur.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
