Make None a subclass of int [alternative to iNaN]
Hi all, 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? Sharing, Ken Hilton;
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.
I'm -1 on this idea. None is and should remain domain-independent. Specific domains may require additional special values like "NaN", "+/-inf", etc. for floating point math, in which case it makes more sense to define a domain-specific special value than compromise the independence of None. Doing so could break code that assumes None is only an instance of NoneType: if isinstance(x, int): handle_integer(x) else if x is None: handle_none() On Sun, Sep 30, 2018 at 1:06 AM Ken Hilton <kenlhilton@gmail.com> wrote:
Hi all,
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?
Sharing, Ken Hilton;
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (3)
-
Abe Dillon -
Ken Hilton -
Serhiy Storchaka