But then you might as

> well make it a built-in name, which would behave almost exactly

> the same way, and Guido doesn't want to do that.

Do you have a reference for that preference? And Guido is no longer the BDFL, though of course, very well respected opinion.

and you'll see that the magic constants (eg True) have an AST node of

type "Constant", as do literals that represent constants.

That sounds like the “right” thing to do with this, if anything. 

similar to name lookups than to constants, and it'd definitely need

special handling inside literal_eval.

Which is why just adding these to the builtin names doesn’t quite do it.

it'd be way WAY cleaner to

just build a function similar to literal_eval that permits exactly the

operations you're okay with.

Sure, that would be the way to make a “PYSON” reader like I would like, but that’s not really the goal of this proposal, such as it is — making “inf” work with literal_eval is not so much the goal, as a shorthand for what I guess is:

Make “inf” and “nan” Constants.

The idea is that, if the names have not been defined in that scope, they would behave like any other literal everywhere in Python.

I’m actually liking this more as I think about it. And it seems it wouldn’t actually break any code that currently defines those names. And in many cases, it would do the same thing as those names currently do, if a bit differently. 

That is, if you removed:

from math import inf

From your code, nothing would break. 

I honestly don’t think I want this enough to try to push it through, but it’s a


From me, for what that’s worth (two cents, maybe? )


Christopher Barker, PhD

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