Mailman 3 September 2011 - Python-checkins

cpython: pymacro.h: Inline _Py_ARRAY_LENGTH_CHECK() and add http://ccodearchive.net/
by victor.stinner Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/d2bac6e41f71 changeset: 72523:d2bac6e41f71 user: Victor Stinner <vstinner(a)wyplay.com> date: Thu Sep 29 12:12:39 2011 +0200 summary: pymacro.h: Inline _Py_ARRAY_LENGTH_CHECK() and add http://ccodearchive.net/ files: Include/pymacro.h | 25 ++++++++++++------------- 1 files changed, 12 insertions(+), 13 deletions(-) diff --git a/Include/pymacro.h b/Include/pymacro.h --- a/Include/pymacro.h +++ b/Include/pymacro.h @@ -19,20 +19,10 @@ ((char *)(foo) \ + Py_BUILD_ASSERT(offsetof(struct foo, string) == 0)) - Written by Rusty Russell, public domain. */ + Written by Rusty Russell, public domain, http://ccodearchive.net/ */ #define Py_BUILD_ASSERT(cond) \ (sizeof(char [1 - 2*!(cond)]) - 1) -#if defined(__GNUC__) -/* Two gcc extensions. - &a[0] degrades to a pointer: a different type from an array */ -#define _Py_ARRAY_LENGTH_CHECK(array) \ - Py_BUILD_ASSERT(!__builtin_types_compatible_p(typeof(array), \ - typeof(&(array)[0]))) -#else -#define _Py_ARRAY_LENGTH_CHECK(array) 0 -#endif - /* Get the number of elements in a visible array @@ -40,9 +30,18 @@ parameters. With correct compiler support, such usage will cause a build error (see Py_BUILD_ASSERT). - Written by Rusty Russell, public domain. */ + Written by Rusty Russell, public domain, http://ccodearchive.net/ */ +#if defined(__GNUC__) +/* Two gcc extensions. + &a[0] degrades to a pointer: a different type from an array */ #define Py_ARRAY_LENGTH(array) \ - (sizeof(array) / sizeof((array)[0]) + _Py_ARRAY_LENGTH_CHECK(array)) + (sizeof(array) / sizeof((array)[0]) \ + + Py_BUILD_ASSERT(!__builtin_types_compatible_p(typeof(array), \ + typeof(&(array)[0])))) +#else +#define Py_ARRAY_LENGTH(array) \ + (sizeof(array) / sizeof((array)[0])) +#endif /* Define macros for inline documentation. */ -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge default -> default): Merge heads.
by ezio.melotti Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/e7672fe3cd35 changeset: 72522:e7672fe3cd35 parent: 72520:e6a2b54c1d16 parent: 72521:ba6ee5cc9ed6 user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Thu Sep 29 08:36:23 2011 +0300 summary: Merge heads. files: Doc/whatsnew/3.3.rst | 63 +++++++++++++++++++++---------- 1 files changed, 42 insertions(+), 21 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 @@ -58,35 +58,56 @@ PEP 393: Flexible String Representation ======================================= +XXX Give a short introduction about :pep:`393`. + +PEP 393 is fully backward compatible. The legacy API should remain +available at least five years. Applications using the legacy API will not +fully benefit of the memory reduction, or worse may use a little bit more +memory, because Python may have to maintain two versions of each string (in +the legacy format and in the new efficient storage). + XXX Add list of changes introduced by :pep:`393` here: +* Python now always supports the full range of Unicode codepoints, including + non-BMP ones (i.e. from ``U+0000`` to ``U+10FFFF``). The distinction between + narrow and wide builds no longer exists and Python now behaves like a wide + build. + +* 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 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 small summary about + performances and a link to the PEP should be added here. + +* Some of the problems visible on narrow builds have been fixed, for example: + + * :func:`len` now always returns 1 for non-BMP characters, + so ``len('\U0010FFFF') == 1``; + + * surrogate pairs are not recombined in string literals, + so ``'\uDBFF\uDFFF' != '\U0010FFFF'``; + + * indexing or slicing a non-BMP characters doesn't return surrogates anymore, + so ``'\U0010FFFF'[0]`` now returns ``'\U0010FFFF'`` and not ``'\uDBFF'``; + + * several other functions in the stdlib now handle correctly non-BMP codepoints. + * The value of :data:`sys.maxunicode` is now always ``1114111`` (``0x10FFFF`` in hexadecimal). The :c:func:`PyUnicode_GetMax` function still returns either ``0xFFFF`` or ``0x10FFFF`` for backward compatibility, and it should not be used with the new Unicode API (see :issue:`13054`). -* Non-BMP characters (U+10000-U+10FFFF range) are no more special cases. - ``'\U0010FFFF'[0]`` is now ``'\U0010FFFF'`` on any platform, instead of - ``'\uDFFF'`` on narrow build or ``'\U0010FFFF'`` on wide build. And - ``len('\U0010FFFF')`` is now ``1`` on any platform, instead of ``2`` on - narrow build or ``1`` on wide build. More generally, most bugs related to - non-BMP characters are now fixed. For example, :func:`unicodedata.normalize` - handles correctly non-BMP characters on all platforms. +* The :file:`./configure` flag ``--with-wide-unicode`` has been removed. -* The storage of Unicode string is now adapted on the content of the string. - Pure ASCII and Latin1 strings (U+0000-U+00FF) use 1 byte per character, BMP - strings (U+0000-U+FFFF) use 2 bytes per character, and non-BMP characters - (U+10000-U+10FFFF range) use 4 bytes per characters. 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>`_. - -* The PEP 393 is fully backward compatible. The legacy API should remain - available at least five years. Applications using the legacy API will not - fully benefit of the memory reduction, or worse may use a little bit more - memory, because Python may have to maintain two versions of each string (in - the legacy format and in the new efficient storage). - +XXX mention new and deprecated functions and macros Other Language Changes ====================== -- Repository URL: http://hg.python.org/cpython

1 0

cpython: Update and reorganize the whatsnew entry for PEP 393.
by ezio.melotti Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/ba6ee5cc9ed6 changeset: 72521:ba6ee5cc9ed6 parent: 72516:90fef68f06e7 user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Thu Sep 29 08:34:36 2011 +0300 summary: Update and reorganize the whatsnew entry for PEP 393. files: Doc/whatsnew/3.3.rst | 63 +++++++++++++++++++++---------- 1 files changed, 42 insertions(+), 21 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 @@ -58,35 +58,56 @@ PEP 393: Flexible String Representation ======================================= +XXX Give a short introduction about :pep:`393`. + +PEP 393 is fully backward compatible. The legacy API should remain +available at least five years. Applications using the legacy API will not +fully benefit of the memory reduction, or worse may use a little bit more +memory, because Python may have to maintain two versions of each string (in +the legacy format and in the new efficient storage). + XXX Add list of changes introduced by :pep:`393` here: +* Python now always supports the full range of Unicode codepoints, including + non-BMP ones (i.e. from ``U+0000`` to ``U+10FFFF``). The distinction between + narrow and wide builds no longer exists and Python now behaves like a wide + build. + +* 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 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 small summary about + performances and a link to the PEP should be added here. + +* Some of the problems visible on narrow builds have been fixed, for example: + + * :func:`len` now always returns 1 for non-BMP characters, + so ``len('\U0010FFFF') == 1``; + + * surrogate pairs are not recombined in string literals, + so ``'\uDBFF\uDFFF' != '\U0010FFFF'``; + + * indexing or slicing a non-BMP characters doesn't return surrogates anymore, + so ``'\U0010FFFF'[0]`` now returns ``'\U0010FFFF'`` and not ``'\uDBFF'``; + + * several other functions in the stdlib now handle correctly non-BMP codepoints. + * The value of :data:`sys.maxunicode` is now always ``1114111`` (``0x10FFFF`` in hexadecimal). The :c:func:`PyUnicode_GetMax` function still returns either ``0xFFFF`` or ``0x10FFFF`` for backward compatibility, and it should not be used with the new Unicode API (see :issue:`13054`). -* Non-BMP characters (U+10000-U+10FFFF range) are no more special cases. - ``'\U0010FFFF'[0]`` is now ``'\U0010FFFF'`` on any platform, instead of - ``'\uDFFF'`` on narrow build or ``'\U0010FFFF'`` on wide build. And - ``len('\U0010FFFF')`` is now ``1`` on any platform, instead of ``2`` on - narrow build or ``1`` on wide build. More generally, most bugs related to - non-BMP characters are now fixed. For example, :func:`unicodedata.normalize` - handles correctly non-BMP characters on all platforms. +* The :file:`./configure` flag ``--with-wide-unicode`` has been removed. -* The storage of Unicode string is now adapted on the content of the string. - Pure ASCII and Latin1 strings (U+0000-U+00FF) use 1 byte per character, BMP - strings (U+0000-U+FFFF) use 2 bytes per character, and non-BMP characters - (U+10000-U+10FFFF range) use 4 bytes per characters. 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>`_. - -* The PEP 393 is fully backward compatible. The legacy API should remain - available at least five years. Applications using the legacy API will not - fully benefit of the memory reduction, or worse may use a little bit more - memory, because Python may have to maintain two versions of each string (in - the legacy format and in the new efficient storage). - +XXX mention new and deprecated functions and macros Other Language Changes ====================== -- Repository URL: http://hg.python.org/cpython

1 0

Daily reference leaks (991ef9253263): sum=0
by solipsis＠pitrou.net Sept. 29, 2011

Sept. 29, 2011

results for 991ef9253263 on branch "default" -------------------------------------------- Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogIi1ufB', '-x']

1 0

cpython: Fix hex_digit_to_int() prototype: expect Py_UCS4, not Py_UNICODE
by victor.stinner Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/e6a2b54c1d16 changeset: 72520:e6a2b54c1d16 user: Victor Stinner <victor.stinner(a)haypocalc.com> date: Thu Sep 29 04:02:13 2011 +0200 summary: Fix hex_digit_to_int() prototype: expect Py_UCS4, not Py_UNICODE files: Objects/bytearrayobject.c | 4 ++-- Objects/bytesobject.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Objects/bytearrayobject.c b/Objects/bytearrayobject.c --- a/Objects/bytearrayobject.c +++ b/Objects/bytearrayobject.c @@ -1147,7 +1147,7 @@ \n\ Remove all items from B."); -static PyObject * +static PyObject * bytearray_clear(PyByteArrayObject *self) { if (PyByteArray_Resize((PyObject *)self, 0) < 0) @@ -2629,7 +2629,7 @@ Example: bytearray.fromhex('B9 01EF') -> bytearray(b'\\xb9\\x01\\xef')."); static int -hex_digit_to_int(Py_UNICODE c) +hex_digit_to_int(Py_UCS4 c) { if (c >= 128) return -1; diff --git a/Objects/bytesobject.c b/Objects/bytesobject.c --- a/Objects/bytesobject.c +++ b/Objects/bytesobject.c @@ -593,7 +593,7 @@ quote = '"'; if (squotes && quote == '\'') newsize += squotes; - + if (newsize > (PY_SSIZE_T_MAX - sizeof(PyUnicodeObject) - 1)) { PyErr_SetString(PyExc_OverflowError, "bytes object is too large to make repr"); @@ -2330,7 +2330,7 @@ Example: bytes.fromhex('B9 01EF') -> b'\\xb9\\x01\\xef'."); static int -hex_digit_to_int(Py_UNICODE c) +hex_digit_to_int(Py_UCS4 c) { if (c >= 128) return -1; -- Repository URL: http://hg.python.org/cpython

1 0

cpython: _io.textio: fix character type, use Py_UCS4 instead of Py_UNICODE
by victor.stinner Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/8f4b162f9f0e changeset: 72518:8f4b162f9f0e user: Victor Stinner <victor.stinner(a)haypocalc.com> date: Thu Sep 29 03:28:17 2011 +0200 summary: _io.textio: fix character type, use Py_UCS4 instead of Py_UNICODE files: Modules/_io/textio.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Modules/_io/textio.c b/Modules/_io/textio.c --- a/Modules/_io/textio.c +++ b/Modules/_io/textio.c @@ -347,7 +347,7 @@ memchr(in_str, '\n', PyUnicode_KIND_SIZE(kind, len)) != NULL) { Py_ssize_t i = 0; for (;;) { - Py_UNICODE c; + Py_UCS4 c; /* Fast loop for non-control characters */ while (PyUnicode_READ(kind, in_str, i) > '\n') i++; @@ -1570,7 +1570,7 @@ } -/* NOTE: `end` must point to the real end of the Py_UNICODE storage, +/* NOTE: `end` must point to the real end of the Py_UCS4 storage, that is to the NUL character. Otherwise the function will produce incorrect results. */ static char * @@ -1614,7 +1614,7 @@ for (;;) { Py_UCS4 ch; /* Fast path for non-control chars. The loop always ends - since the Py_UNICODE storage is NUL-terminated. */ + since the Unicode string is NUL-terminated. */ while (PyUnicode_READ(kind, s, 0) > '\r') s += size; if (s >= end) { -- Repository URL: http://hg.python.org/cpython

1 0

cpython: modsupport.c reuses Py_UNICODE_strlen()
by victor.stinner Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/204d9391889a changeset: 72519:204d9391889a user: Victor Stinner <victor.stinner(a)haypocalc.com> date: Thu Sep 29 04:01:43 2011 +0200 summary: modsupport.c reuses Py_UNICODE_strlen() files: Python/modsupport.c | 11 +---------- 1 files changed, 1 insertions(+), 10 deletions(-) diff --git a/Python/modsupport.c b/Python/modsupport.c --- a/Python/modsupport.c +++ b/Python/modsupport.c @@ -148,15 +148,6 @@ return v; } -static int -_ustrlen(Py_UNICODE *u) -{ - int i = 0; - Py_UNICODE *v = u; - while (*v != 0) { i++; v++; } - return i; -} - static PyObject * do_mktuple(const char **p_format, va_list *p_va, int endchar, int n, int flags) { @@ -269,7 +260,7 @@ } else { if (n < 0) - n = _ustrlen(u); + n = Py_UNICODE_strlen(u); v = PyUnicode_FromUnicode(u, n); } return v; -- Repository URL: http://hg.python.org/cpython

1 0

cpython: _sre: don't use Py_UNICODE anymore
by victor.stinner Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/e4a80a1a9e18 changeset: 72517:e4a80a1a9e18 user: Victor Stinner <victor.stinner(a)haypocalc.com> date: Thu Sep 29 03:27:47 2011 +0200 summary: _sre: don't use Py_UNICODE anymore * Downcasting from Py_UCS4 to Py_UNICODE is wrong is Py_UNICODE is 16-bit wchar_t * Remove old special case in getstring(), unicode is now handled separetely files: Modules/_sre.c | 16 +++++++--------- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/Modules/_sre.c b/Modules/_sre.c --- a/Modules/_sre.c +++ b/Modules/_sre.c @@ -163,15 +163,15 @@ /* unicode-specific character predicates */ -#define SRE_UNI_IS_DIGIT(ch) Py_UNICODE_ISDECIMAL((Py_UNICODE)(ch)) -#define SRE_UNI_IS_SPACE(ch) Py_UNICODE_ISSPACE((Py_UNICODE)(ch)) -#define SRE_UNI_IS_LINEBREAK(ch) Py_UNICODE_ISLINEBREAK((Py_UNICODE)(ch)) -#define SRE_UNI_IS_ALNUM(ch) Py_UNICODE_ISALNUM((Py_UNICODE)(ch)) -#define SRE_UNI_IS_WORD(ch) (SRE_UNI_IS_ALNUM((ch)) || (ch) == '_') +#define SRE_UNI_IS_DIGIT(ch) Py_UNICODE_ISDECIMAL(ch) +#define SRE_UNI_IS_SPACE(ch) Py_UNICODE_ISSPACE(ch) +#define SRE_UNI_IS_LINEBREAK(ch) Py_UNICODE_ISLINEBREAK(ch) +#define SRE_UNI_IS_ALNUM(ch) Py_UNICODE_ISALNUM(ch) +#define SRE_UNI_IS_WORD(ch) (SRE_UNI_IS_ALNUM(ch) || (ch) == '_') static unsigned int sre_lower_unicode(unsigned int ch) { - return (unsigned int) Py_UNICODE_TOLOWER((Py_UNICODE)(ch)); + return (unsigned int) Py_UNICODE_TOLOWER(ch); } LOCAL(int) @@ -1674,7 +1674,7 @@ return ptr; } - /* get pointer to string buffer */ + /* get pointer to byte string buffer */ view.len = -1; buffer = Py_TYPE(string)->tp_as_buffer; if (!buffer || !buffer->bf_getbuffer || @@ -1702,8 +1702,6 @@ if (PyBytes_Check(string) || bytes == size) charsize = 1; - else if (bytes == (Py_ssize_t) (size * sizeof(Py_UNICODE))) - charsize = sizeof(Py_UNICODE); else { PyErr_SetString(PyExc_TypeError, "buffer size mismatch"); return NULL; -- Repository URL: http://hg.python.org/cpython

1 0

peps: Fix typos and whitespace in PEP-393.
by ezio.melotti Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/peps/rev/48b81244ae34 changeset: 3951:48b81244ae34 user: Ezio Melotti date: Thu Sep 29 04:56:12 2011 +0300 summary: Fix typos and whitespace in PEP-393. files: pep-0393.txt | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/pep-0393.txt b/pep-0393.txt --- a/pep-0393.txt +++ b/pep-0393.txt @@ -118,7 +118,7 @@ (implies ready) - ascii: the object uses the PyASCIIObject representation (implies compact and ready) -- ready: the canonical represenation is ready to be accessed through +- ready: the canonical representation is ready to be accessed through PyUnicode_DATA and PyUnicode_GET_LENGTH. This is set either if the object is compact, or the data pointer and length have been initialized. @@ -160,7 +160,7 @@ In particular, codecs using this API must compute both the number of characters and the maximum character in advance. An string is allocated according to the specified size and character range and is -null-terminated; the actual characters in it may be unitialized. +null-terminated; the actual characters in it may be uninitialized. PyUnicode_FromString and PyUnicode_FromStringAndSize remain supported for processing UTF-8 input; the input is decoded, and the UTF-8 @@ -188,7 +188,7 @@ PyUnicode_2BYTE_KIND (2), or PyUnicode_4BYTE_KIND (3). PyUnicode_DATA gives the void pointer to the data. Access to individual characters should use PyUnicode_{READ|WRITE}[_CHAR]: - + - PyUnciode_READ(kind, data, index) - PyUnicode_WRITE(kind, data, index, value) - PyUnicode_READ_CHAR(unicode, index) @@ -240,7 +240,7 @@ Character access utility functions: -- PyUnicode_GetLength(o), PyUnicode_ReadChar(o, index), +- PyUnicode_GetLength(o), PyUnicode_ReadChar(o, index), PyUnicode_WriteChar(o, index, character) - PyUnicode_CopyCharacters(to, to_start, from, from_start, how_many) - PyUnicode_FindChar(str, ch, start, end, direction) @@ -296,7 +296,7 @@ PyUnicode_EncodeUnicodeEscape, PyUnicode_EncodeRawUnicodeEscape, PyUnicode_EncodeLatin1, PyUnicode_EncodeASCII, PyUnicode_EncodeCharmap, PyUnicode_TranslateCharmap, - PyUnicode_EncodeMBCS, PyUnicode_EncodeDecimal, + PyUnicode_EncodeMBCS, PyUnicode_EncodeDecimal, PyUnicode_TransformDecimalToASCII - Py_UNICODE_{strlen, strcat, strcpy, strcmp, strchr, strrchr} - PyUnicode_AsUnicodeCopy @@ -314,7 +314,7 @@ pointer. Such code will break with this PEP. The code was already flawed in 3.2, as there is was no explicit guarantee that the PyUnicode_AS_UNICODE result would stay valid after an API call (due to -the possiblity of string resizing). Modules that face this issue +the possibility of string resizing). Modules that face this issue need to re-fetch the Py_UNICODE pointer after API calls; doing so will continue to work correctly in earlier Python versions. @@ -395,7 +395,7 @@ indexing works well for PyUnicode_READ(_CHAR) and PyUnicode_WRITE. Use void* as the buffer type for characters to let the compiler detect invalid dereferencing operations. If you do want to use pointer -arithmentics (e.g. when converting existing code), use (unsigned) +arithmetics (e.g. when converting existing code), use (unsigned) char* as the buffer type, and keep the element size (1, 2, or 4) in a variable. Notice that (1<<(kind-1)) will produce the element size given a buffer kind. @@ -428,7 +428,7 @@ For common tasks, direct access to the string representation may not be necessary: PyUnicode_Find, PyUnicode_FindChar, PyUnicode_Ord, and PyUnicode_CopyCharacters help in analyzing and creating string -objects, operating on indices instead of data pointers. +objects, operating on indexes instead of data pointers. References ========== -- Repository URL: http://hg.python.org/peps

1 0

cpython: Remove now useless redefinition of chr/ord for narrow builds in
by ezio.melotti Sept. 29, 2011

Sept. 29, 2011

http://hg.python.org/cpython/rev/90fef68f06e7 changeset: 72516:90fef68f06e7 user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Thu Sep 29 04:36:38 2011 +0300 summary: Remove now useless redefinition of chr/ord for narrow builds in test_multibytecodec_support.py. files: Lib/test/test_multibytecodec_support.py | 15 ------------- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/Lib/test/test_multibytecodec_support.py b/Lib/test/test_multibytecodec_support.py --- a/Lib/test/test_multibytecodec_support.py +++ b/Lib/test/test_multibytecodec_support.py @@ -264,21 +264,6 @@ self.assertEqual(ostream.getvalue(), self.tstring[0]) -if len('\U00012345') == 2: # ucs2 build - _unichr = chr - def chr(v): - if v >= 0x10000: - return _unichr(0xd800 + ((v - 0x10000) >> 10)) + \ - _unichr(0xdc00 + ((v - 0x10000) & 0x3ff)) - else: - return _unichr(v) - _ord = ord - def ord(c): - if len(c) == 2: - return 0x10000 + ((_ord(c[0]) - 0xd800) << 10) + \ - (ord(c[1]) - 0xdc00) - else: - return _ord(c) class TestBase_Mapping(unittest.TestCase): pass_enctest = [] -- Repository URL: http://hg.python.org/cpython

1 0