Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Martin v. Löwis
>> 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

Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Stefan Behnel
"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

Re: [Python-Dev] fcmp() in test.support

2011-01-29 Thread Nick Coghlan
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

Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Nick Coghlan
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

Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Antoine Pitrou
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

Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Stefan Behnel
"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

Re: [Python-Dev] PEP 393: Flexible String Representation

2011-01-29 Thread Alexander Belopolsky
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.