Looks like Parser/asdl_c.py did not get all the way updated when _Py_identifier switched over to _Py_IDENTIFER.  I've included a patch that fixes it (though it's relatively trivial).  With this fix I did not notice any further problems.

Good catch.  I see what happened.  7109f31300fb updated
Python/Python-ast.c but not Parser/asdl_c.py.  I will apply your patch 
shortly.  Thanks.

Oh, and just to be clear I reproduced the build break by doing:

./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl
make

in a built tree.  The reason that this wasn't caught is that the make
rules have the ASDL files as dependencies on the AST C files.  So, the
C files are *not* updated unless the ASDL files are.

Maybe we should change the build system to always regenerate the files
or add something to automation that regenerates the AST C file every
time.

New changeset 941d015053c6 by Meador Inge in branch 'default':
Issue 13243: Rename _Py_identifier to _Py_IDENTIFIER in asdl_c.py
http://hg.python.org/cpython/rev/941d015053c6

Committed.  Thanks!

> Maybe we should change the build system to always regenerate the files
> or add something to automation that regenerates the AST C file every
> time.

Most definitely not. It is very deliberate that asdl_c.py is only
invoked when the ASDL sources change. Otherwise, having Python installed
would be a build requirement for Python, which it must be not.

> Most definitely not. It is very deliberate that asdl_c.py is only
> invoked when the ASDL sources change. Otherwise, having Python installed
> would be a build requirement for Python, which it must be not.

OK, thanks for the background.  To be clear, though, the build dependency
is already there.  You just have to touch the ASDL sources to run
into it (Lib/opcode.py as well).  This is even documented in the
Makefile*:

# XXX Note that a build now requires Python exist before the build starts
ASDLGEN=	 $(srcdir)/Parser/asdl_c.py

However, modifying the ASDL source is, with respect to other source
modifications, not as common.  So, I see no reason to make the situation worse
by running asd_c.py all the time.  Suggestion withdrawn.

* If not relying on an external Python is a hard requirement (and I do
see why that may be useful),
then the build system could be changed to only allow changes to
problematic sources
(ASDL, opcode.py) after Python has been built once.  Then the built
Python could be used.

Am 23.10.2011 20:33, schrieb Meador Inge:
> 
> Meador Inge <meadori@gmail.com> added the comment:
> 
>> Most definitely not. It is very deliberate that asdl_c.py is only
>> invoked when the ASDL sources change. Otherwise, having Python installed
>> would be a build requirement for Python, which it must be not.
> 
> OK, thanks for the background.  To be clear, though, the build dependency
> is already there.  You just have to touch the ASDL sources to run
> into it (Lib/opcode.py as well).  This is even documented in the
> Makefile*:

Just to be more clear: normally, generated files shouldn't be checked
into the source repository. However, exceptions are typically made for
generated files that may be difficult to regenerate on some target
systems. For Python, this includes configure (depends on autoconf being
run), and various files generated from Python scripts (also including
the Unicode database, for example).

So when we check in generated files, the build dependency becomes unused
unless the source file gets modified - which, as you point out, happens
rarely, and never happens for somebody who just wants to build Python.

> * If not relying on an external Python is a hard requirement (and I do
> see why that may be useful), then the build system could be changed to only allow changes to
> problematic sources (ASDL, opcode.py) after Python has been built once.  Then the built
> Python could be used.

See above. It's fine to require core contributors to have Python
installed (and also autoconf). We just need to make sure that
Python is not required on the target system (as people may try
to install Python initially on that system).