On Mon, 1 Oct 2018 at 00:00, Chris Angelico <ros...@gmail.com> wrote: > > On Mon, Oct 1, 2018 at 8:53 AM Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: > > > > On Sun, 30 Sep 2018 at 02:01, Steven D'Aprano <st...@pearwood.info> wrote: > > > > > > On Sat, Sep 29, 2018 at 09:43:42PM +0100, Oscar Benjamin wrote: > > > > On Sat, 29 Sep 2018 at 19:38, Steve Barnes <gadgetst...@live.co.uk> > > > > wrote: > > > > > > > > > I converted to int because I needed a whole number, this was > > > > > > intended to > > > > > represent some more complex process where a value is converted to a > > > > > whole number down in the depths of the processing. > > > > > > > > Your requirement to have a whole number cannot meaningfully be > > > > satisfied if your input is nan so an exception is the most useful > > > > result. > > > > > > Not to Steve it isn't. > > > > > > Be careful about making value judgements like that: Steve is asking for > > > an integer NAN because for *him* an integer NAN is more useful than an > > > exception. You shouldn't tell him that he is wrong, unless you know his > > > use-case and his code, which you don't. > > > > Then he can catch the exception and do something else. If I called > > int(x) because my subsequent code "needed a whole number" then I would > > definitely not want to end up with a nan. The proposal requested is > > that int(x) could return something other than a well defined integer. > > That would break a lot of code! > > At no point was the behaviour of int(x) ever proposed to be changed. > Don't overreact here.
The context got trimmed a bit too much. You can see here the messages preceding what is quoted above: https://mail.python.org/pipermail/python-ideas/2018-September/053840.html Quoting here: > One simplistic example would be print(int(float('nan'))) (gives a ValueError) > while print(int(iNaN)) should give 'nan' or maybe 'inan' That would mean that the result of int(x) is no longer guaranteed to be a well-defined integer. > The recommended use-case was for a library to > return iNaN instead of None when it is unable to return an actual > value. You can already use None or float('nan') for this. You can also create your own singleton nan object if you want. When I said I haven't seen a use-case what I mean is that no one has presented a situation where the existing language facilities are considered insufficient (apart from the suggestion about int(iNaN) that I refer to above). -- Oscar _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
