Message295909
It's intended behaviour, but you're right that we don't explicitly document anywhere that SyntaxError can be reported from three different places:
- the initial parsing based on the language Grammar
- the conversion of the parse tree into the AST
- the conversion of the AST into a runtime code object
It isn't possible to separate the first two from pure Python code, but ast.parse() (aka the ast.PyCF_ONLY_AST compile flag) skips the last one.
As Michał noted, it's usually that last stage which checks for "higher level" constructs related to lexical structure, where certain statements can only be meaningfully executed when used inside a suitable compound statement, but can still be parsed outside it:
```
>>> ast.dump(ast.parse("break"))
'Module(body=[Break()])'
>>> ast.dump(ast.parse("continue"))
'Module(body=[Continue()])'
>>> ast.dump(ast.parse("return"))
'Module(body=[Return(value=None)])'
>>> ast.dump(ast.parse("yield"))
'Module(body=[Expr(value=Yield(value=None))])'
```
(`await` currently isn't in that category, but that's specifically due to the parser hacks used to enable it without needing a __future__ import)
The appropriate fix would probably be to add a sentence to the `ast.PyCF_ONLY_AST` documentation to say that some syntax errors are only detected when compiling the AST to a code object. |
|
Date |
User |
Action |
Args |
2017-06-13 12:10:56 | ncoghlan | set | recipients:
+ ncoghlan, hniksic, docs@python, enedil |
2017-06-13 12:10:56 | ncoghlan | set | messageid: <1497355856.56.0.710678326693.issue30637@psf.upfronthosting.co.za> |
2017-06-13 12:10:56 | ncoghlan | link | issue30637 messages |
2017-06-13 12:10:56 | ncoghlan | create | |
|