Message333421
I don't really expect this to go anywhere until Python 4 (*maybe* 3.9 after a deprecation period), but it seems like it would have been a good idea to make NotImplementedType's __bool__ explicitly raise a TypeError (rather than leaving it unset, so NotImplemented evaluates as truthy). Any correct use of NotImplemented per its documented intent would never evaluate it in a boolean context, but rather use identity testing, e.g. back in the Py2 days, the canonical __ne__ delegation to __eq__ for any class should be implemented as something like:
def __ne__(self, other):
equal = self.__eq__(other)
return equal if equal is NotImplemented else not equal
Problem is, a lot of folks would make mistakes like doing:
def __ne__(self, other):
return not self.__eq__(other)
which silently returns False when __eq__ returns NotImplemented, rather than returning NotImplemented and allowing Python to check the mirrored operation. Similar issues arise when hand-writing the other rich comparison operators in terms of each other.
It seems like, given NotImplemented is a sentinel value that should never be evaluated in a boolean context, at some point it might be nice to explicitly prevent it, to avoid errors like this.
Main argument against it is that I don't know of any other type/object that explicitly makes itself unevaluable in a boolean context, so this could be surprising if someone uses NotImplemented as a sentinel unrelated to its intended purpose and suffers the problem. |
|
Date |
User |
Action |
Args |
2019-01-10 21:55:08 | josh.r | set | recipients:
+ josh.r |
2019-01-10 21:55:06 | josh.r | set | messageid: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org> |
2019-01-10 21:55:06 | josh.r | link | issue35712 messages |
2019-01-10 21:55:05 | josh.r | create | |
|