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/

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/