30.09.18 09:05, Ken Hilton пише:
Reading the iNaN discussion, most of the opposition seems to be that adding iNaN would add a new special value to integers and therefore add new complexity.
I propose, instead, that we make None a subclass of int (or even a certain value of int) to represent iNaN. Therefore:
>>> None + 1, None - 1, None * 2, None / 2, None // 2 (None, None, None, nan, None) # mathematical operations on NaN return NaN >>> None & 1, None | 1, None ^ 1 # I'm not sure about this one. The following could be plausible: (0, 1, 1) # or this might make more sense, as this *is* NaN we're talking about: (None, None, None) >>> isinstance(None, int) True # the whole point of this idea >>> issubclass(type(None), int) True # no matter whether None *is* an int or just a subclass, this will be true as issubclass(int, int) is True
I know this is a crazy idea, but I thought it could have some merit, so why not throw it out here?
This will make some errors passing silently (instead of raising a TypeError or AttributeError earlier) and either cause errors far from the initial place or producing an incorrect result.