[Python-ideas] Suggestion: Extend integers to include iNaN

Steve Barnes gadgetsteve at live.co.uk
Sun Sep 30 09:41:24 EDT 2018



On 30/09/2018 13:55, Steven D'Aprano wrote:
> On Sun, Sep 30, 2018 at 12:09:45PM +0300, Serhiy Storchaka wrote:
>> 30.09.18 04:07, Steven D'Aprano пише:
>>> Telling people that they don't understand their own code when you don't
>>> know their code is not very productive.
>>
>> I can't tell him what he should do with his (not working) code, but it
>> doesn't look like a good justification for changes in the Python core.
> 
> You don't know that his code is not working. For all you know, Steve has
> working code that works around the lack of an int NAN in some other,
> more clumsy, less elegant, ugly and slow way.
> 
> NANs are useful for when you don't want a calculation to halt on certain
> errors, or on missing data. That ability of a NAN to propogate through
> the calculation instead of halting can be useful when your data are
> ints, not just floats or Decimals.
> 
> Earlier, I suggested that this proposal would probably be best done as a
> subclass of int. It certainly should be prototyped as a subclass before
> we consider making a builtin int NAN. Since Steve has already agreed to
> work on that first, I think any further discussion would be pointless
> until he comes back to us. He may decide that a subclass solves his
> problem and no longer want a builtin int NAN.
> 
> 
I have had (over the years) a lot of working code with lots of checks in 
and a huge number of paths through due to the lack of such of iNaN, or 
something to return for "that didn't work", floats & complex have NaN, 
strings have empty string list and sets can be empty but there is no 
such option for integers. Hence the suggestion. I am hartened that the 
authors of the Decimal library also felt the need for NaN (as well as 
INF & -INF).

I am roughing out such a class and some test cases which will hopefully 
include some cases where the hoped for advantages can be realised.

My thinking on bitwise operations is to do the same as arithmetic 
operations, i.e. (anything op iNaN) = iNaN and likewise for shift 
operations.
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
https://www.avg.com



More information about the Python-ideas mailing list