Stowage/cpython
2
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2026-01-08 00:12:42 +00:00
Code Issues Projects Releases Packages Wiki Activity

Add subheaders to make PEP 393 description clearer

Browse source
This commit is contained in:
Antoine Pitrou 2011-11-29 22:45:07 +01:00
parent c8e032006a
commit 0599b5b2a1
1 changed files with 28 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

50
Doc/whatsnew/3.3.rst
View file

@ -69,6 +69,9 @@ API will not fully benefit of the memory reduction, or - worse - may use
a bit more memory, because Python may have to maintain two versions of each
string (in the legacy format and in the new efficient storage).
Functionality
-------------
Changes introduced by :pep:`393` are the following:
* Python now always supports the full range of Unicode codepoints, including
@ -76,28 +79,6 @@ Changes introduced by :pep:`393` are the following:
narrow and wide builds no longer exists and Python now behaves like a wide
build, even under Windows.
* The storage of Unicode strings now depends on the highest codepoint in the string:
* pure ASCII and Latin1 strings (``U+0000-U+00FF``) use 1 byte per codepoint;
* BMP strings (``U+0000-U+FFFF``) use 2 bytes per codepoint;
* non-BMP strings (``U+10000-U+10FFFF``) use 4 bytes per codepoint.
The net effect is that for most applications, memory usage of string storage
should decrease significantly - especially compared to former wide unicode
builds - as, in many cases, strings will be pure ASCII even in international
contexts (because many strings store non-human language data, such as XML
fragments, HTTP headers, JSON-encoded data, etc.). We also hope that it
will, for the same reasons, increase CPU cache efficiency on non-trivial
applications.
.. The memory usage of Python 3.3 is two to three times smaller than Python 3.2,
and a little bit better than Python 2.7, on a `Django benchmark
<http://mail.python.org/pipermail/python-dev/2011-September/113714.html>`_.
XXX The result should be moved in the PEP and a link to the PEP should
be added here.
* With the death of narrow builds, the problems specific to narrow builds have
also been fixed, for example:
@ -120,6 +101,31 @@ Changes introduced by :pep:`393` are the following:
* The :file:`./configure` flag ``--with-wide-unicode`` has been removed.
Performance and resource usage
------------------------------
The storage of Unicode strings now depends on the highest codepoint in the string:
* pure ASCII and Latin1 strings (``U+0000-U+00FF``) use 1 byte per codepoint;
* BMP strings (``U+0000-U+FFFF``) use 2 bytes per codepoint;
* non-BMP strings (``U+10000-U+10FFFF``) use 4 bytes per codepoint.
The net effect is that for most applications, memory usage of string storage
should decrease significantly - especially compared to former wide unicode
builds - as, in many cases, strings will be pure ASCII even in international
contexts (because many strings store non-human language data, such as XML
fragments, HTTP headers, JSON-encoded data, etc.). We also hope that it
will, for the same reasons, increase CPU cache efficiency on non-trivial
applications.
.. The memory usage of Python 3.3 is two to three times smaller than Python 3.2,
and a little bit better than Python 2.7, on a `Django benchmark
<http://mail.python.org/pipermail/python-dev/2011-September/113714.html>`_.
XXX The result should be moved in the PEP and a link to the PEP should
be added here.
PEP 3151: Reworking the OS and IO exception hierarchy
=====================================================