Re: [Python-Dev] PEP 393: Flexible String Representation
>> 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 in the future as long as they only use the 'str' pointer > and not 'wstr'. Py_UNICODE isn't part of the stable ABI, so it wasn't important for extensions using the stable ABI before - so really no change here. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393: Flexible String Representation
"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 that work on unicode buffers in the future as long as they only use the 'str' pointer and not 'wstr'. Py_UNICODE isn't part of the stable ABI, so it wasn't important for extensions using the stable ABI before - so really no change here. 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 change based on build time options. OTOH, one could argue that this is already partly provided by the generic buffer API. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fcmp() in test.support
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 stuff in this module. As Eli noted, we explicitly disclaim all stability guarantees when it comes to this module. Documenting it properly is intended to make it easier to write high quality tests using the utilities we have developed over the years without having to read the source code. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393: Flexible String Representation
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 first. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393: Flexible String Representation
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 change based on build time options. > > OTOH, one could argue that this is already partly provided by the generic > buffer API. Unicode objects don't provide the buffer API (and chances are they never will). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393: Flexible String Representation
"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 one byte per character for strings that are pure ASCII (which will be the majority of strings for the majority of users). You'll find the PEP at http://www.python.org/dev/peps/pep-0393/ [...] The Py_UNICODE type is still supported but deprecated. It is always defined as a typedef for wchar_t, so the wstr representation can double as Py_UNICODE representation. 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? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393: Flexible String Representation
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. Docs should be fixed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
