Mailman 3 September 2008 - Python-checkins

r66629 - python/trunk/Doc/howto/cporting.rst
by georg.brandl 26 Sep '08

26 Sep '08

Author: georg.brandl Date: Fri Sep 26 23:15:21 2008 New Revision: 66629 Log: typos. Modified: python/trunk/Doc/howto/cporting.rst Modified: python/trunk/Doc/howto/cporting.rst ============================================================================== --- python/trunk/Doc/howto/cporting.rst (original) +++ python/trunk/Doc/howto/cporting.rst Fri Sep 26 23:15:21 2008 @@ -27,13 +27,13 @@ #endif API functions that are not present can be aliased to their equivalents within -conditional block. +conditional blocks. Changes to Object APIs ====================== -Python 3.0 merged together some types with simliar functions while cleanly +Python 3.0 merged together some types with similar functions while cleanly separating others. @@ -121,7 +121,7 @@ Python 3.0 has a revamped extension module initialization system. (See PEP :pep:`3121`.) Instead of storing module state in globals, they should be stored -in a interpreter specific structure. Creating modules that act correctly in +in an interpreter specific structure. Creating modules that act correctly in both 2.x and 3.0 is tricky. The following simple example demonstrates how. :: #include "Python.h"

1 0

r66628 - python/trunk/Doc/howto/cporting.rst
by benjamin.peterson 26 Sep '08

26 Sep '08

Author: benjamin.peterson Date: Fri Sep 26 22:52:06 2008 New Revision: 66628 Log: add an 'other options' section Modified: python/trunk/Doc/howto/cporting.rst Modified: python/trunk/Doc/howto/cporting.rst ============================================================================== --- python/trunk/Doc/howto/cporting.rst (original) +++ python/trunk/Doc/howto/cporting.rst Fri Sep 26 22:52:06 2008 @@ -206,3 +206,12 @@ return module; #endif } + + +Other options +============= + +If you are writing a new extension module, you might consider `Cython +<http://www.cython.org>`_. It translates a Python-like language to C. The +extension modules it creates are compatible with Python 3.x and 2.x. +

1 0

buildbot failure in x86 osx.5 2.5
by buildbot＠python.org 26 Sep '08

26 Sep '08

The Buildbot has detected a new failure of x86 osx.5 2.5. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20osx.5%202.5/builds/40 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: heller-x86-osx5 Build Reason: Build Source Stamp: [branch branches/release25-maint] HEAD Blamelist: georg.brandl BUILD FAILED: failed test Excerpt from the test logfile: 1 test failed: test_socket make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0

r66627 - in python/branches/release25-maint: Lib/lib-tk/turtle.py Misc/NEWS
by georg.brandl 26 Sep '08

26 Sep '08

Author: georg.brandl Date: Fri Sep 26 09:17:03 2008 New Revision: 66627 Log: #3968: fix missing update() call in end_fill(). Modified: python/branches/release25-maint/Lib/lib-tk/turtle.py python/branches/release25-maint/Misc/NEWS Modified: python/branches/release25-maint/Lib/lib-tk/turtle.py ============================================================================== --- python/branches/release25-maint/Lib/lib-tk/turtle.py (original) +++ python/branches/release25-maint/Lib/lib-tk/turtle.py Fri Sep 26 09:17:03 2008 @@ -306,6 +306,7 @@ {'fill': self._color, 'smooth': smooth}) self._items.append(item) + self._canvas.update() self._path = [] self._filling = flag if flag: Modified: python/branches/release25-maint/Misc/NEWS ============================================================================== --- python/branches/release25-maint/Misc/NEWS (original) +++ python/branches/release25-maint/Misc/NEWS Fri Sep 26 09:17:03 2008 @@ -89,6 +89,8 @@ Library ------- +- Issues #3968 and #3969: two minor turtle problems. + - Issue #3547: Fixed ctypes structures bitfields of varying integer sizes.

1 0

r66626 - python/branches/release25-maint/Lib/lib-tk/turtle.py
by georg.brandl 26 Sep '08

26 Sep '08

Author: georg.brandl Date: Fri Sep 26 09:14:57 2008 New Revision: 66626 Log: #3969: fix typo in turtle.py. Modified: python/branches/release25-maint/Lib/lib-tk/turtle.py Modified: python/branches/release25-maint/Lib/lib-tk/turtle.py ============================================================================== --- python/branches/release25-maint/Lib/lib-tk/turtle.py (original) +++ python/branches/release25-maint/Lib/lib-tk/turtle.py Fri Sep 26 09:14:57 2008 @@ -762,7 +762,7 @@ startx = geometry.get('startx', _startx) if startx >= 0 or startx == None: - _startx = _startx + _startx = startx else: raise ValueError, "startx can not be less than 0"

1 0

r66625 - in python/trunk/Doc/howto: cporting.rst index.rst
by benjamin.peterson 26 Sep '08

26 Sep '08

Author: benjamin.peterson Date: Fri Sep 26 04:58:36 2008 New Revision: 66625 Log: add the beginnings of a C-API 2 -> 3 porting guide Added: python/trunk/Doc/howto/cporting.rst (contents, props changed) Modified: python/trunk/Doc/howto/index.rst Added: python/trunk/Doc/howto/cporting.rst ============================================================================== --- (empty file) +++ python/trunk/Doc/howto/cporting.rst Fri Sep 26 04:58:36 2008 @@ -0,0 +1,208 @@ +.. highlightlang:: c + +******************************** +Porting Extension Modules to 3.0 +******************************** + +:author: Benjamin Peterson + + +.. topic:: Abstract + + Although changing the C-API was not one of Python 3.0's objectives, the many + Python level changes made leaving 2.x's API intact impossible. In fact, some + changes such as :func:`int` and :func:`long` unification are more obvious on + the C level. This document endeavors to document incompatibilities and how + they can be worked around. + + +Conditional compilation +======================= + +The easiest way to compile only some code for 3.0 is to check if +:cmacro:`PY_MAJOR_VERSION` is greater than or equal to 3. :: + + #if PY_MAJOR_VERSION >= 3 + #define IS_PY3K + #endif + +API functions that are not present can be aliased to their equivalents within +conditional block. + + +Changes to Object APIs +====================== + +Python 3.0 merged together some types with simliar functions while cleanly +separating others. + + +str/unicode Unification +----------------------- + + +Python 3.0's :func:`str` (``PyString_*`` functions in C) type is equivalent to +2.x's :func:`unicode` (``PyUnicode_*``). The old 8-bit string type has become +:func:`bytes`. Python 2.6 and later provide a compatibility header, +:file:`bytesobject.h`, mapping ``PyBytes`` names to ``PyString`` ones. For best +interpolation with 3.0, :ctype:`PyUnicode` should be used for textual data and +:ctype:`PyBytes` for binary data. It's also important to remember that +:ctype:`PyBytes` and :ctype:`PyUnicode` in 3.0 are not interchangeable like +:ctype:`PyString` and :ctype:`PyString` are in 2.x. The following example shows +best practices with regards to :ctype:`PyUnicode`, :ctype:`PyString`, and +:ctype:`PyBytes`. :: + + #include "stdlib.h" + #include "Python.h" + #include "bytesobject.h" + + /* text example */ + static PyObject * + say_hello(PyObject *self, PyObject *args) { + PyObject *name, *result; + + if (!PyArg_ParseTuple(args, "U:say_hello", &name)) + return NULL; + + result = PyUnicode_FromFormat("Hello, %S!", name); + return result; + } + + static char * do_encode(PyObject *); + + /* bytes example */ + static PyObject * + encode_object(PyObject *self, PyObject *args) { + char *encoded; + PyObject *result, *myobj; + + if (!PyArg_ParseTuple(args, "O:encode_object", &myobj)) + return NULL; + + encoded = do_encode(myobj); + if (encoded == NULL) + return NULL; + result = PyBytes_FromString(encoded); + free(encoded); + return result; + } + + +long/int Unification +-------------------- + +In Python 3.0, there is only one integer type. It is called :func:`int` on the +Python level, but actually corresponds to 2.x's :func:`long` type. In the +C-API, ``PyInt_*`` functions are replaced by their ``PyLong_*`` neighbors. The +best course of action here is probably aliasing ``PyInt_*`` functions to +``PyLong_*`` variants or using the abstract ``PyNumber_*`` APIs. :: + + #include "Python.h" + + #if PY_MAJOR_VERSION >= 3 + #define PyInt_FromLong PyLong_FromLong + #endif + + static PyObject * + add_ints(PyObject *self, PyObject *args) { + int one, two; + PyObject *result; + + if (!PyArg_ParseTuple(args, "ii:add_ints", &one, &two)) + return NULL; + + return PyInt_FromLong(one + two); + } + + + +Module initialization and state +=============================== + +Python 3.0 has a revamped extension module initialization system. (See PEP +:pep:`3121`.) Instead of storing module state in globals, they should be stored +in a interpreter specific structure. Creating modules that act correctly in +both 2.x and 3.0 is tricky. The following simple example demonstrates how. :: + + #include "Python.h" + + struct module_state { + PyObject *error; + }; + + #if PY_MAJOR_VERSION >= 3 + #define GETSTATE(m) ((struct module_state*)PyModule_GetState(m)) + #else + #define GETSTATE(m) (&_state) + static struct module_state _state; + #endif + + static PyObject * + error_out(PyObject *m) { + struct module_state *st = GETSTATE(m); + PyErr_SetString(st->error, "something bad happened"); + return NULL; + } + + static PyMethodDef myextension_methods[] = { + {"error_out", (PyCFunction)error_out, METH_NOARGS, NULL}, + {NULL, NULL} + }; + + #if PY_MAJOR_VERSION >= 3 + + static int myextension_traverse(PyObject *m, visitproc visit, void *arg) { + Py_VISIT(GETSTATE(m)->error); + return 0; + } + + static int myextension_clear(PyObject *m) { + Py_CLEAR(GETSTATE(m)->error); + return 0; + } + + + static struct PyModuleDef moduledef = { + PyModuleDef_HEAD_INIT, + "myextension", + NULL, + sizeof(struct module_state), + myextension_methods, + NULL, + myextension_traverse, + myextension_clear, + NULL + }; + + #define INITERROR return NULL + + PyObject * + PyInit_myextension(void) + + #else + #define INITERROR return + + void + initmyextension(void) + #endif + { + #if PY_MAJOR_VERSION >= 3 + PyObject *module = PyModule_Create(&moduledef); + #else + PyObject *module = Py_InitModule("myextension", myextension_methods); + #endif + + if (module == NULL) + INITERROR; + struct module_state *st = GETSTATE(module); + + st->error = PyErr_NewException("myextension.Error", NULL, NULL); + if (st->error == NULL) { + Py_DECREF(module); + INITERROR; + } + + #if PY_MAJOR_VERSION >= 3 + return module; + #endif + } Modified: python/trunk/Doc/howto/index.rst ============================================================================== --- python/trunk/Doc/howto/index.rst (original) +++ python/trunk/Doc/howto/index.rst Fri Sep 26 04:58:36 2008 @@ -14,6 +14,7 @@ :maxdepth: 1 advocacy.rst + cporting.rst curses.rst doanddont.rst functional.rst

1 0

buildbot failure in sparc solaris10 gcc 3.0
by buildbot＠python.org 26 Sep '08

26 Sep '08

The Buildbot has detected a new failure of sparc solaris10 gcc 3.0. Full details are available at: http://www.python.org/dev/buildbot/all/sparc%20solaris10%20gcc%203.0/builds… Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: loewis-sun Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: amaury.forgeotdarc BUILD FAILED: failed test Excerpt from the test logfile: 1 test failed: test_posix ====================================================================== ERROR: test_getcwd_long_pathnames (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home2/buildbot/slave/3.0.loewis-sun/build/Lib/test/test_posix.py", line 252, in test_getcwd_long_pathnames support.rmtree(base_path) File "/home2/buildbot/slave/3.0.loewis-sun/build/Lib/test/support.py", line 98, in rmtree shutil.rmtree(path) File "/home2/buildbot/slave/3.0.loewis-sun/build/Lib/shutil.py", line 225, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/home2/buildbot/slave/3.0.loewis-sun/build/Lib/shutil.py", line 223, in rmtree os.rmdir(path) OSError: [Errno 22] Invalid argument: '/home2/buildbot/slave/3.0.loewis-sun/build/@test.getcwd/@test.getcwd' sincerely, -The Buildbot

1 0

r66624 - in python/trunk/Lib: collections.py test/test_collections.py
by raymond.hettinger 25 Sep '08

25 Sep '08

Author: raymond.hettinger Date: Fri Sep 26 01:31:52 2008 New Revision: 66624 Log: Fix namedtuple bug reported by Glenn Linderman. Template did not form correctly if the field names were input in Unicode. Modified: python/trunk/Lib/collections.py python/trunk/Lib/test/test_collections.py Modified: python/trunk/Lib/collections.py ============================================================================== --- python/trunk/Lib/collections.py (original) +++ python/trunk/Lib/collections.py Fri Sep 26 01:31:52 2008 @@ -38,7 +38,7 @@ # generating informative error messages and preventing template injection attacks. if isinstance(field_names, basestring): field_names = field_names.replace(',', ' ').split() # names separated by whitespace and/or commas - field_names = tuple(field_names) + field_names = tuple(map(str, field_names)) for name in (typename,) + field_names: if not all(c.isalnum() or c=='_' for c in name): raise ValueError('Type names and field names can only contain alphanumeric characters and underscores: %r' % name) Modified: python/trunk/Lib/test/test_collections.py ============================================================================== --- python/trunk/Lib/test/test_collections.py (original) +++ python/trunk/Lib/test/test_collections.py Fri Sep 26 01:31:52 2008 @@ -34,6 +34,11 @@ namedtuple('Point0', 'x1 y2') # Verify that numbers are allowed in names namedtuple('_', 'a b c') # Test leading underscores in a typename + nt = namedtuple('nt', u'the quick brown fox') # check unicode input + self.assert_("u'" not in repr(nt._fields)) + nt = namedtuple('nt', (u'the', u'quick')) # check unicode input + self.assert_("u'" not in repr(nt._fields)) + self.assertRaises(TypeError, Point._make, [11]) # catch too few args self.assertRaises(TypeError, Point._make, [11, 22, 33]) # catch too many args

1 0

buildbot failure in x86 osx.5 3.0
by buildbot＠python.org 25 Sep '08

25 Sep '08

The Buildbot has detected a new failure of x86 osx.5 3.0. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20osx.5%203.0/builds/420 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: heller-x86-osx5 Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: amaury.forgeotdarc BUILD FAILED: failed test Excerpt from the test logfile: 4 tests failed: test_calendar test_email test_mailbox test_socket ====================================================================== ERROR: testShutdown (test.test_socket.BasicTCPTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.0.heller-x86-osx5/build/Lib/test/test_socket.py", line 121, in _tearDown self.fail(msg) AssertionError: [Errno 57] Socket is not connected make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0

buildbot failure in g4 osx.4 3.0
by buildbot＠python.org 25 Sep '08

25 Sep '08

The Buildbot has detected a new failure of g4 osx.4 3.0. Full details are available at: http://www.python.org/dev/buildbot/all/g4%20osx.4%203.0/builds/1447 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: psf-g4 Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: amaury.forgeotdarc BUILD FAILED: failed test Excerpt from the test logfile: 1 test failed: test_asynchat make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0