>> None of the functions in this PEP become part of the stable ABI.
>
> I think that's only part of the truth. This PEP can potentially have an
> impact on the stable ABI in the sense that the build-time size of
> Py_UNICODE may no longer be important for extensions that work on
> unicode buffers
"Martin v. Löwis", 29.01.2011 10:05:
None of the functions in this PEP become part of the stable ABI.
I think that's only part of the truth. This PEP can potentially have an
impact on the stable ABI in the sense that the build-time size of
Py_UNICODE may no longer be important for extensions th
On Sat, Jan 29, 2011 at 5:34 AM, Michael Foord
wrote:
> This module shouldn't really be documented at all. It exists to support the
> Python test framework and we don't want to have to support users or make API
> stability guarantees. Plus most of it is rather old. Please don't document
> more stu
On Sat, Jan 29, 2011 at 8:00 PM, Stefan Behnel wrote:
> OTOH, one could argue that this is already partly provided by the generic
> buffer API.
Which won't be part of the stable ABI until 3.3 - there are some
discrepancies between PEP 3118 and the actual implementation that we
need to sort out fi
On Sat, 29 Jan 2011 11:00:48 +0100
Stefan Behnel wrote:
>
> I know, that's not what I meant. But this PEP would enable a C API that
> provides direct access to the underlying buffer. Just as is currently
> provided for the Py_UNICODE array, but with a stable ABI because the buffer
> type won't
"Martin v. Löwis", 24.01.2011 21:17:
I'd like to propose PEP 393, which takes a different approach,
addressing both problems simultaneously: by getting a flexible
representation (one that can be either 1, 2, or 4 bytes), we can
support the full range of Unicode on all systems, but still use
only
On Sat, Jan 29, 2011 at 12:03 PM, Stefan Behnel wrote:
..
> What about the character property functions?
>
> http://docs.python.org/py3k/c-api/unicode.html#unicode-character-properties
>
> Will they be adapted to accept Py_UCS4 instead of Py_UNICODE?
They have been already. See revision 84177.