http://hg.python.org/cpython/rev/3e295f2a47b9 changeset: 73791:3e295f2a47b9 user: Antoine Pitrou <solipsis@pitrou.net> date: Tue Nov 29 22:45:07 2011 +0100 summary: Add subheaders to make PEP 393 description clearer files: Doc/whatsnew/3.3.rst | 50 +++++++++++++++++-------------- 1 files changed, 28 insertions(+), 22 deletions(-) diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst --- a/Doc/whatsnew/3.3.rst +++ b/Doc/whatsnew/3.3.rst @@ -69,6 +69,9 @@ 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 @@ 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 @@ * 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 ===================================================== -- Repository URL: http://hg.python.org/cpython