This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients docs@python, enedil, hniksic, ncoghlan
Date 2017-06-13.12:10:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1497355856.56.0.710678326693.issue30637@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-06-13 12:10:56ncoghlansetrecipients: + ncoghlan, hniksic, docs@python, enedil
2017-06-13 12:10:56ncoghlansetmessageid: <1497355856.56.0.710678326693.issue30637@psf.upfronthosting.co.za>
2017-06-13 12:10:56ncoghlanlinkissue30637 messages
2017-06-13 12:10:56ncoghlancreate