>>> inf =3
>>> eval(repr([1.0, 2.0, float('inf')]))


Obviously these are edge cases, and we could spent all day going over particular cases which the repr -> eval identity doesn't hold. However I still think that, as a principle, it's a solid one. I think changing the repr of 'inf' to 'float('inf')' is a decent solution (but keeping str conversion the same).

So, I guess in order to reduce backwards incompatibility, the repr could be modified to return a string which actually generates an infinite value



On Sat, Sep 5, 2020, 8:14 PM David Mertz <mertz@gnosis.cx> wrote:
On Sat, Sep 5, 2020 at 7:26 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 6/09/20 8:08 am, David Mertz wrote:
> The only real goal I've seen is that you hope that `x == eval(repr(x))`
> for floating point numbers.  But that is doomed to failure since it
> cannot work for NaN by its very definition.

I think that just means the definition needs a bit more finesse.
It would be a reasonable goal for it to give back *some* NaN
with the same flags and payload as the original.

Sure, but we have that already:

>>> from math import inf, nan
>>> eval(repr([42, nan, inf]))
[42, nan, inf]

The only difference is the `math` namespace vs `builtins` namespace.

--
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HP5R24IXRL5LST3OQWWNNTALHLUCIVUN/
Code of Conduct: http://python.org/psf/codeofconduct/