I am a -0 on this, but I think it was Greg Ewing that presented a real use case: 

There is no way to use literal_eval that gets you an inf (or NaN value).

Which is a real, though maybe not important, use case.

-CHB

On Fri, Sep 4, 2020 at 7:15 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Sep 04, 2020 at 09:40:55PM -0400, Cade Brown wrote:

> The `eval(repr(x)) == x` is not a segment of my code; rather it is part of

> Python's description of what 'repr' should do:

>

> https://docs.python.org/3.4/library/functions.html?highlight=repr#repr

>

>

> Specifically: ` For many types, this function makes an attempt to return a

> string that would yield an object with the same value when passed to eval()`

> <https://docs.python.org/3.4/library/functions.html?highlight=repr#eval>



"For many types" and "makes an attempt".



There has never been, and never will be, a guarantee that all objects

will obey that invariant. As I said, it is a Nice To Have, and it is

designed for convenience at the interactive interpreter.





> So everyone in this thread can stop mentioning security concerns; I'm sure

> we're all aware of those and we should instead focus on what repr should do

> and shouldn't do.



You specifically said that math.inf doesn't solve your problem *because*

`eval(repr(x))` doesn't work. Now you are backpeddling and saying that

this is not your actual problem.



(In fact it does work, if you do it correctly.)



There are a million other objects that don't obey that invariant:



    py> x = object()

    py> eval(repr(x)) == x

    SyntaxError: invalid syntax





Why is float infinity so special that it needs to obey the

invariant?



What's the actual problem, or problems, in your code that you are trying

to solve by making an infinity builtin? If there is no actual problem

being solved, and the only reason you want this is because:





> I think it's weird to not fulfill this promise





you don't have any sympathy from me:



- `eval(repr(x))` is not a promise, it is a mere suggestion

  that *some* types *try* to provide.



- Adding a special built-in constant Infinity just to satisfy

  this Nice To Have feature is overkill.



- It would require float infinities to change their repr from

  'inf' to 'Infinity', and that will break doctests.



- And even if that feature were satisfied by infinity, it

  couldn't be satisfied by float NANs by their very definition:



    py> from math import nan

    py> nan == nan

    False



So while the cost of adding a new Infinity builtin is small, the benefit

is even smaller.





--

Steve

_______________________________________________

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/AHJETD7PM6M6IKERP7NYNGYWAJBZDS27/

Code of Conduct: http://python.org/psf/codeofconduct/

--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython