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 <kenlhil...@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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/