In the docs for the try statement [1], part of the grammar is:

try1_stmt ::=  "try" ":" suite
               ("except" [expression ["as" target]] ":" suite)+
               ["else" ":" suite]
               ["finally" ":" suite]

The `target` rule allows any assignable expression (identifier, attributes, etc.). However, CPython appears to only allow identifiers as a target. The abstract grammar in the ast module [2] appears to confirm this.

[1] https://docs.python.org/3.4/reference/compound_stmts.html#the-try-statement
[2] https://docs.python.org/3.4/library/ast.html#abstract-grammar

Yes. Seems to be a documentation error. The full grammar specification [1] uses 'NAME' instead of 'target'.

[1]: https://docs.python.org/3/reference/grammar.html

The whole page on compound statements seems to be rife with inconsistencies.

I think 'target' can just be replaced by 'identifier'.
Using 'expression' (or 'expr' in the ast doc) for what should be 'exceptions: identifier' or paranthesized tuple of identifiers;, is also too broad. However, that must be enforced in the compiler rather than the parser, and compiler restrictions are in the text, not the grammar.

> Using 'expression' (or 'expr' in the ast doc) for what should be 'exceptions: identifier' or paranthesized tuple of identifiers;, is also too broad. However, that must be enforced in the compiler rather than the parser, and compiler restrictions are in the text, not the grammar.

I would expect any expression to be valid so long as it evaluates at runtime to an exception type (or tuple of exception types), so the use of expression seems correct to me. In other words, the following is valid Python (but would not be allowed if I've understood your statement correctly):

    def f():
        try:
            "".blah
        except some_error():
            print("caught")
            
    def some_error():
        return AttributeError

    f()

You are right, only the result, and not the form of 'expression' is constrained. I will let Jayanth propose other errors.

The page on compound statements defines compound statements as:

compound_stmt ::=  if_stmt
                   | while_stmt
                   | for_stmt
                   | try_stmt
                   | with_stmt
                   | funcdef
                   | classdef

The full grammar specification on the other hand says:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated

This accordingly leads to different definitions of funcdef and classdef. This is not necessarily 'incorrect', but for the sake of clarity, it might be better if both pages followed the same conventions.

The grammar presented in the doc is intentionally slightly simplified from the one actually used by the LL(1) parser.  The parser has to know what type of statement it is parsing after the first token or so, so it needs a separate production (concept) for statements that start with '@'.  Human readers are more capable and can look backwards from 'def' and 'class'.

A separate section on 'Decorated statements' would be possible, but not necessarily better. A section of 'Decorators' (without calling them 'statements') would be slightly different and also possible.  Discussion would have to start on Python ideas and any action a separate issue.

Oh ok. That makes sense.

New changeset 5496bf8972b6 by Terry Jan Reedy in branch '2.7':
Issue #22243: fix except grammar in reference.
http://hg.python.org/cpython/rev/5496bf8972b6

New changeset a249f1f879be by Terry Jan Reedy in branch '3.4':
Issue #22243: fix except grammar in reference.
http://hg.python.org/cpython/rev/a249f1f879be