Łukasz Langa <luk...@langa.pl> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32911> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
