`ast.literal_eval` is very strict on names, so it seems to lack some "literals" that may be result of `repr` on built-in objects.

-> Obvious cases:

ast.literal_eval('...')
ast.literal_eval('Ellipsis')

both result on ValueError.



-> Not so obvious:

nan_name = repr(float('nan'))
ast.literal_eval(nan_name) # ValueError

inf_name = repr(float('inf'))
ast.literal_eval(inf_name)  # ValueError

ast.literal_eval("2e308") # == inf


`nan` and `inf` are not literals (at least "inf" should be, but that's another problem), but their representations are not possible to be evaluated unlike any other float numbers with maybe precision loss. 

I think `literal_eval` should include these 3 names the same way it accepts True, False and None.

Another case, that I personally don't care, but seems plausible would be `NotImplemented`.

eval(repr(float('nan'))) doesn't work either, so I'm not sure ast.literal_eval should. The same with float('inf').

That's what I said by `nan` and `inf` are not literals, but their representations look like they should be.

One solution could be to add another argument to allow some extra names. Maybe a mapping, as `eval`.

I don't think literal_eval should handle anything which is not syntax.

> I don't think literal_eval should handle anything which is not syntax.
+1

-1 on supporting 'inf' and 'nan'
-0 on supporting 'Ellipsis' or '...';  seems harmless, but I don't really see the point.

Of course `nan` and `inf` are part of the syntax! The `ast.parse` function recognize them as `Name`. 

So that works:

>>> ast.dump(ast.parse('True'))
"Module(body=[Expr(value=Name(id='True', ctx=Load()))])"

>>> ast.dump(ast.parse('inf'))
"Module(body=[Expr(value=Name(id='inf', ctx=Load()))])"

>>> inf = float('inf')
>>> eval('inf')
inf

I've run into some literals with `Ellipsis` and `inf` and couldn't load them with literal_eval. That's why I'm proposing that.

The thing about `nan` and `inf` is because they are the *only* representations of float numbers produced by the interpreter that cannot be loaded.

Something like that could solve the problem keeping `literal_eval` safe and allowing other names:

ast.literal_eval('[1.0, 2.0, inf]', {'inf': float('inf')})

I like the 'safe_names' idea, but is this patch supposed to work?

>>> isinstance(None, Ellipsis)
TypeError: isinstance() arg 2 must be a type or tuple of types

Ellipsis in this context is `_ast.Ellipsis`, not the original one...

There's no TypeError there as `_ast.Ellipsis` is a class.

Ah right, that's confusing indeed...

Unit tests and doc updates are needed though.

Thanks for the patch.  It looks good to me, but I think that adding support for Ellipsis and adding a new parameter to allow extra names are two different requests, but someone more knowledgeable than me about AST may judge differently.  My rationale is that supporting Ellipsis literals is a no-brainer addition, whereas adding an argument to support things that are not actual Python literals may be rejected.  You don’t have to split your patch in two anyway, it’s easy to do if the dev who will commit wants to.

Each change would also need a doc update.

Just to be sure: What's a doc update? The `.rst` files are updated automatically with the doc strings?

The adding another argument should require a:
"Changed in version 3.x: Accepts a second argument ..." ?

No, the rst documentation is maintained manually.

Look for versionchanged in the doc source files or the documentation about writing documentation to see how to document the new argument (and new supported Ellipsis literal).