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.