_Py_IDENTIFIER(xxx) defines a variable called PyId_xxx, so xxx can
only be ASCII: the C language doesn't accept non-ASCII identifiers.
That's not exactly true. In C89, source code is in the source character
set, which is implementation-defined, except that it must contain
the basic character
2012/2/7 Martin v. Löwis mar...@v.loewis.de:
_Py_IDENTIFIER(xxx) defines a variable called PyId_xxx, so xxx can
only be ASCII: the C language doesn't accept non-ASCII identifiers.
That's not exactly true. In C89, source code is in the source character
set, which is implementation-defined,
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
-gps
___
Python-Dev mailing list
Python-Dev@python.org
2012/2/7 Gregory P. Smith g...@krypto.org
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
The Microsoft compilers on Windows do not support C99:
- Declarations must be at the
Does C99 specify the encoding? Can we expect UTF-8?
No, it's implementation-defined. However, that really doesn't matter
much for the macro (it does matter for the Mercurial repository):
The files on disk are mapped, in an implementation-defined manner,
into the source character set. All
Am 07.02.2012 20:10, schrieb Gregory P. Smith:
Why do we still care about C89? It is 2012 and we're talking about
Python 3. What compiler on what platform that anyone actually cares
about does not support C99?
As Amaury says: Visual Studio still doesn't support C99. The story is
both funny
I'd rather restore support for allowing UTF-8 source here (I don't think
that requiring ASCII really improves much), than rename the macro.
Done, I reverted my change.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
I realize that _Py_Identifier is a private name, and that PEP 3131
requires anything (except test cases) in the standard library to stick
with ASCII ... but somehow, that feels like too long of a chain.
I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier,
or at least a comment
I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier,
or at least a comment stating that Identifiers will (per PEP 3131)
always be ASCII -- preferably with an assert to back that up.
Please ... no.
This is a *convenience* interface, whose sole purpose is to make something
more
2012/2/6 Jim Jewett jimjjew...@gmail.com:
I realize that _Py_Identifier is a private name, and that PEP 3131
requires anything (except test cases) in the standard library to stick
with ASCII ... but somehow, that feels like too long of a chain.
I would prefer to see _Py_Identifier renamed to
On Mon, 6 Feb 2012 22:57:46 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
- id-object = PyUnicode_DecodeUTF8Stateful(id-string,
- strlen(id-string),
- NULL, NULL);
+
11 matches
Mail list logo
