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 firstname.lastname@example.org wrote:
On Sat, Sep 5, 2020 at 7:26 PM Greg Ewing email@example.com 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 -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/HP5R24... Code of Conduct: http://python.org/psf/codeofconduct/