ast.literal_eval does not accept code with leading whitespaces, while eval accepts them, which is an inconsistency.

>>> import ast
>>> eval(' 1')
1
>>> ast.literal_eval(' 1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/usr/local/lib/python3.9/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    1
IndentationError: unexpected indent

Looks like skipping the leading whitespace is an undocumented behavior for eval() introduced back in 1992 (f08ab0a). I don't think that bringing it to the literal_eval is a good idea, at least after this much of a time. If so, both of them should be explicitly documented or at least mentioned in the source code (to avoid confusion).

Hm, I'm not sure. ast.literal_eval() does accept trailing whitespace, and embedded whitespace.

>>> ast.literal_eval("- ( 1\n)\n")
-1
>>> 

So I think it should start accepting leading whitespace too (but only in a feature release, so 3.10).

The doc for literal_eval says "evaluate ... a string containing a Python literal or container display." To me, ' 1' qualifies, just as it does as an expression for eval().

The exception comes from parsing raising IndentationError with leading whitespace even when the mode is 'eval' rather than 'exec'. This surprised me. Eval() gets strips the beginning of the string before it is parsed. If parsing remains as is, I agree that doing the same for literal_eval strings. But why should not parsing remove indents for 'eval' mode?

[Terry]

But why should not parsing remove indents for 'eval' mode?

I dunno, but it's been doing this since 1992, so I think it would be fragile to change. The best thing therefore is to make ast.literal_eval() match it exactly.

I dunno, but it's been doing this since 1992, so I think it would be fragile to change. The best thing therefore is to make ast.literal_eval() match it exactly.

+1 We had considerable finicky behaviour in the parser related to new lines and whitespace so I would recommend to strive for stability.

New changeset e799aa8 by Batuhan Taskaya in branch 'master':
bpo-41887: omit leading spaces/tabs on ast.literal_eval (bpo-22469)
e799aa8

Closing. Let’s not backport.