> 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
http://mail.python.org/m
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
> 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 proces
2012/2/7 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?
>
The Microsoft compilers on Windows do not support C99:
- Declarations must be at the start of a b
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
http://mail.python.org/mailman/lis
2012/2/7 "Martin v. Löwis" :
>> _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
> _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 characte
On Mon, 6 Feb 2012 22:57:46 +0100
Victor Stinner wrote:
>
> >> - id->object = PyUnicode_DecodeUTF8Stateful(id->string,
> >> - strlen(id->string),
> >> - NULL, NULL);
> >> + id->object =
2012/2/6 Jim Jewett :
> 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_Identi
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 c
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 sta
11 matches
Mail list logo