Add a comment explaining why _PyUnicode_FromId can (and should) assume ASCII-only identifiers.


	/* PEP3131 guarantees that all python-internal identifiers
	   are ASCII-only.  Violating this would break some supported
	   C compilers. */

See http://mail.python.org/pipermail/python-dev/2012-February/116234.html

This has nothing to do with PEP 3131. Python could (and does) support non-ASCII identifiers just fine, regardless of C compiler limitations.

On Mon, Feb 6, 2012 at 4:25 PM, Martin v. Löwis <report@bugs.python.org> wrote:

> Martin v. Löwis <martin@v.loewis.de> added the comment:

> This has nothing to do with PEP 3131. Python could (and does)
> support non-ASCII identifiers just fine, regardless of C compiler
> limitations.

I *think* you're saying that the _Py_Identifier( ) is a smaller set
than identifiers in general.  Would the following be more accurate?

        /* PEP3131 does allow non-ASCII identifiers in user code, but
		   limits their use within the implementation itself.
		   In particular, a _Py_Identifier may be passed directly to
		   C code; such identifiers are restricted to ASCII to avoid
		   breaking some supported C compilers. */

And is there a way to characterize the compilers that would break?  Is
it a few specific compilers, or "compilers that do not implement UTF8,
which is not required by the C standard", or ...

Using _Py_static_string(), you can write literal UTF-8 strings using hexadecimal escape sequences. It works on any C compiler. E.g. _Py_static_string(ecute, "\xc3\xa9").

After clarification, the original change was backed out.

These are C Identifiers, and nothing beyond ASCII is guaranteed, but other characters are in practice possible.