Inadasan, what Francis is referring to is that people often use `ast.parse()` to parse code fragments, not entire modules.
For example:
>>> some_code = '"just a string"'
>>> some_code_ast = ast.parse(some_code)
The way `ast.parse()` works, it always considers the input to be a module:
>>> some_code_ast
<_ast.Module object at 0x109537a18>
Before Python 3.7, you could parse out a string from such "module":
>>> some_code.body
[<_ast.Expr object at 0x1079aaa20>]
>>> some_code.body[0].value
<_ast.Str object at 0x107a45198>
However, starting with Python 3.7, this module is empty:
>>> some_code_ast.body
[]
>>> some_code_ast.docstring
'just a string'
`ast.literal_eval()` does not have this problem.
And now: where is the bug? I think the user code has a bug trying to parse a code fragment with `mode="exec"`. Instead of using the default `mode="exec"`, it seems to me `mode="single"` fits the bill better. In some cases the programmer might prefer `mode="eval"` if they don't want to allow statements at all.
Inadasan, I think what we should do is to amend `ast.parse()` and `compile()` docs that mode="exec" treats given code as a module, we should even give the docstring handling as an example.
Francis, if your use case requires passing multiple statements/expressions at once and a string in the first statement has semantic meaning, please provide us with a concrete example.