You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2020-10-04.00:56:32.242>created_at=<Date2020-09-30.01:46:57.482>labels= ['3.8', 'type-feature', 'library', '3.9', '3.10']
title='ast.literal_eval does not accept strings with leading whitespaces'updated_at=<Date2020-10-04.00:56:32.241>user='https://github.com/gousaiyang'
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).
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?