Mailman 3 April 2007 - Python-checkins

r55002 - python/trunk/Doc/tut/tut.tex
by georg.brandl April 27, 2007

April 27, 2007

Author: georg.brandl Date: Fri Apr 27 21:20:00 2007 New Revision: 55002 Modified: python/trunk/Doc/tut/tut.tex Log: Version fix (bug #1708710) Modified: python/trunk/Doc/tut/tut.tex ============================================================================== --- python/trunk/Doc/tut/tut.tex (original) +++ python/trunk/Doc/tut/tut.tex Fri Apr 27 21:20:00 2007 @@ -184,12 +184,12 @@ \file{/usr/local/python} is a popular alternative location.) On Windows machines, the Python installation is usually placed in -\file{C:\e Python24}, though you can change this when you're running +\file{C:\e Python26}, though you can change this when you're running the installer. To add this directory to your path, you can type the following command into the command prompt in a DOS box: \begin{verbatim} -set path=%path%;C:\python24 +set path=%path%;C:\python26 \end{verbatim} @@ -4654,7 +4654,7 @@ >>> os.system('time 0:02') 0 >>> os.getcwd() # Return the current working directory -'C:\\Python24' +'C:\\Python26' >>> os.chdir('/server/accesslogs') \end{verbatim} @@ -5254,7 +5254,7 @@ Traceback (most recent call last): File "<pyshell#108>", line 1, in -toplevel- d['primary'] # entry was automatically removed - File "C:/PY24/lib/weakref.py", line 46, in __getitem__ + File "C:/python26/lib/weakref.py", line 46, in __getitem__ o = self.data[key]() KeyError: 'primary' \end{verbatim}

1 0

r55001 - python/branches/release25-maint/Doc/tut/tut.tex
by georg.brandl April 27, 2007

April 27, 2007

Author: georg.brandl Date: Fri Apr 27 21:19:29 2007 New Revision: 55001 Modified: python/branches/release25-maint/Doc/tut/tut.tex Log: Version fix (bug #1708710) Modified: python/branches/release25-maint/Doc/tut/tut.tex ============================================================================== --- python/branches/release25-maint/Doc/tut/tut.tex (original) +++ python/branches/release25-maint/Doc/tut/tut.tex Fri Apr 27 21:19:29 2007 @@ -184,12 +184,12 @@ \file{/usr/local/python} is a popular alternative location.) On Windows machines, the Python installation is usually placed in -\file{C:\e Python24}, though you can change this when you're running +\file{C:\e Python25}, though you can change this when you're running the installer. To add this directory to your path, you can type the following command into the command prompt in a DOS box: \begin{verbatim} -set path=%path%;C:\python24 +set path=%path%;C:\python25 \end{verbatim} @@ -4654,7 +4654,7 @@ >>> os.system('time 0:02') 0 >>> os.getcwd() # Return the current working directory -'C:\\Python24' +'C:\\Python25' >>> os.chdir('/server/accesslogs') \end{verbatim} @@ -5254,7 +5254,7 @@ Traceback (most recent call last): File "<pyshell#108>", line 1, in -toplevel- d['primary'] # entry was automatically removed - File "C:/PY24/lib/weakref.py", line 46, in __getitem__ + File "C:/python25/lib/weakref.py", line 46, in __getitem__ o = self.data[key]() KeyError: 'primary' \end{verbatim}

1 0

r55000 - sandbox/trunk/2to3/refactor.py
by guido.van.rossum April 27, 2007

April 27, 2007

Author: guido.van.rossum Date: Fri Apr 27 18:45:58 2007 New Revision: 55000 Modified: sandbox/trunk/2to3/refactor.py Log: After replacing 'node' with 'new' in the tree, also move 'new' into the local variable 'node', so a second firing transformation won't hit an assertion. Modified: sandbox/trunk/2to3/refactor.py ============================================================================== --- sandbox/trunk/2to3/refactor.py (original) +++ sandbox/trunk/2to3/refactor.py Fri Apr 27 18:45:58 2007 @@ -259,6 +259,7 @@ if new is not None and (new != node or str(new) != str(node)): node.replace(new) + node = new changes += 1 elif tree.was_changed: changes += 1

1 0

r54999 - sandbox/trunk/2to3/fixes/fix_next.py
by guido.van.rossum April 27, 2007

April 27, 2007

Author: guido.van.rossum Date: Fri Apr 27 18:20:39 2007 New Revision: 54999 Modified: sandbox/trunk/2to3/fixes/fix_next.py Log: Add clone() method to DelayedStrNode class; it may be called. Modified: sandbox/trunk/2to3/fixes/fix_next.py ============================================================================== --- sandbox/trunk/2to3/fixes/fix_next.py (original) +++ sandbox/trunk/2to3/fixes/fix_next.py Fri Apr 27 18:20:39 2007 @@ -14,14 +14,16 @@ bind_warning = "Calls to builtin next() possibly shadowed by global binding" + class DelayedStrNode(object): + def __init__(self, type, base): self.parent = None self.shadowed_next = False self.base = base self.type = type self.value = "" - + def __str__(self): b = "".join([str(n) for n in self.base]) if self.shadowed_next: @@ -29,6 +31,13 @@ else: return "next(%s)" % b + def clone(self): + node = DelayedStrNode(self.type, self.base) + node.shadowed_next = self.shadowed_next + node.value = self.value + return node + + class FixNext(basefix.BaseFix): PATTERN = """ power< base=any+ trailer< '.' 'next' > trailer< '(' ')' > >

1 0

r54995 - python/trunk/Lib/test/test_pty.py
by neal.norwitz April 27, 2007

April 27, 2007

Author: neal.norwitz Date: Fri Apr 27 08:45:32 2007 New Revision: 54995 Modified: python/trunk/Lib/test/test_pty.py Log: This gets the test working on Solaris. It seems a little hokey to me, but the test passed on Linux and Solaris, hopefully other platforms too. Modified: python/trunk/Lib/test/test_pty.py ============================================================================== --- python/trunk/Lib/test/test_pty.py (original) +++ python/trunk/Lib/test/test_pty.py Fri Apr 27 08:45:32 2007 @@ -1,3 +1,5 @@ +import errno +import fcntl import pty import os import sys @@ -40,6 +42,7 @@ # Marginal testing of pty suite. Cannot do extensive 'do or fail' testing # because pty code is not too portable. +# XXX(nnorwitz): these tests leak fds when there is an error. class PtyTest(unittest.TestCase): def setUp(self): # isatty() and close() can hang on some platforms. Set an alarm @@ -70,6 +73,22 @@ self.assertTrue(os.isatty(slave_fd), 'slave_fd is not a tty') + # Solaris requires reading the fd before anything is returned. + # My guess is that since we open and close the slave fd + # in master_open(), we need to read the EOF. + + # Ensure the fd is non-blocking in case there's nothing to read. + orig_flags = fcntl.fcntl(master_fd, fcntl.F_GETFL) + fcntl.fcntl(master_fd, fcntl.F_SETFL, orig_flags | os.O_NONBLOCK) + try: + s1 = os.read(master_fd, 1024) + self.assertEquals('', s1) + except OSError, e: + if e.errno != errno.EAGAIN: + raise + # Restore the original flags. + fcntl.fcntl(master_fd, fcntl.F_SETFL, orig_flags) + debug("Writing to slave_fd") os.write(slave_fd, TEST_STRING_1) s1 = os.read(master_fd, 1024)

2 1

r54998 - peps/trunk/pep-3121.txt
by martin.v.loewis April 27, 2007

April 27, 2007

Author: martin.v.loewis Date: Fri Apr 27 10:31:58 2007 New Revision: 54998 Modified: peps/trunk/pep-3121.txt (contents, props changed) Log: Add keywords for PEP 3121. Modified: peps/trunk/pep-3121.txt ============================================================================== --- peps/trunk/pep-3121.txt (original) +++ peps/trunk/pep-3121.txt Fri Apr 27 10:31:58 2007 @@ -1,7 +1,7 @@ PEP: 3121 Title: Module Initialization and finalization -Version: $Revision: 54994 $ -Last-Modified: $Date: 2007-04-27 08:34:37 +0200 (Fr, 27 Apr 2007) $ +Version: $Revision$ +Last-Modified: $Date$ Author: Martin v. Löwis <martin(a)v.loewis.de> Status: Draft Type: Standards Track

1 0

r54997 - peps/trunk/pep-0000.txt peps/trunk/pep-3121.txt
by martin.v.loewis April 27, 2007

April 27, 2007

Author: martin.v.loewis Date: Fri Apr 27 10:27:24 2007 New Revision: 54997 Added: peps/trunk/pep-3121.txt (contents, props changed) Modified: peps/trunk/pep-0000.txt Log: Add PEP 3121. Modified: peps/trunk/pep-0000.txt ============================================================================== --- peps/trunk/pep-0000.txt (original) +++ peps/trunk/pep-0000.txt Fri Apr 27 10:27:24 2007 @@ -118,6 +118,7 @@ S 3118 Revising the buffer protocol Oliphant, Banks S 3119 Introducing Abstract Base Classes GvR, Talin S 3120 Using UTF-8 as the default source encoding von Löwis + S 3121 Module Initialization and finalization von Löwis S 3141 A Type Hierarchy for Numbers Yasskin Finished PEPs (done, implemented in Subversion) @@ -476,6 +477,7 @@ S 3118 Revising the buffer protocol Oliphant, Banks S 3119 Introducing Abstract Base Classes GvR, Talin S 3120 Using UTF-8 as the default source encoding von Löwis + S 3121 Module Initialization and finalization von Löwis S 3141 A Type Hierarchy for Numbers Yasskin Added: peps/trunk/pep-3121.txt ============================================================================== --- (empty file) +++ peps/trunk/pep-3121.txt Fri Apr 27 10:27:24 2007 @@ -0,0 +1,220 @@ +PEP: 3121 +Title: Module Initialization and finalization +Version: $Revision: 54994 $ +Last-Modified: $Date: 2007-04-27 08:34:37 +0200 (Fr, 27 Apr 2007) $ +Author: Martin v. Löwis <martin(a)v.loewis.de> +Status: Draft +Type: Standards Track +Content-Type: text/x-rst +Created: 27-Apr-2007 +Python-Version: 3.0 +Post-History: + +Abstract +======== + +Module initialization currently has a few deficiencies. There is no +cleanup for modules, the entry point name might give naming conflicts, +the entry functions don't follow the usual calling convention, and +multiple interpreters are not supported well. This PEP addresses these +issues. + +Module Finalization +=================== + +Currently, C modules are initialized usually once and then "live" +forever. The only exception is when Py_Finalize() is called: then +the initialization routine is invoked a second time. This is bad +from a resource management point of view: memory and other resources +might get allocated each time initialization is called, but there +is no way to reclaim them. As a result, there is currently no +way to completely release all resources Python has allocated. + +Entry point name conflicts +========================== + +The entry point is currently called init<module>. This might conflict +with other symbols also called init<something>. In particular, +initsocket is known to have conflicted in the past (this specific +problem got resolved as a side effect of renaming the module to +_socket). + +Entry point signature +===================== + +The entry point is currently a procedure (returning void). This +deviates from the usual calling conventions; callers can find out +whether there was an error during initialization only by checking +PyErr_Occurred. The entry point should return a PyObject*, which will +be the module created, or NULL in case of an exception. + +Multiple Interpreters +===================== + +Currently, extension modules share their state across all +interpreters. This allows for undesirable information leakage across +interpreters: one script could permanently corrupt objects in an +extension module, possibly breaking all scripts in other interpreters. + +Specification +============= + +The module initialization routines change their signature +to:: + + PyObject *PyInit_<modulename>() + +The initialization routine will be invoked once per +interpreter, when the module is imported. It should +return a new module object each time. + +In order to store per-module state in C variables, +each module object will contain a block of memory +that is interpreted only by the module. The amount +of memory used for the module is specified at +the point of creation of the module. + +In addition to the initialization function, a module +may implement a number of additional callback +function, which are invoked when the module's +tp_traverse, tp_clear, and tp_free functions are +invoked, and when the module is reloaded. + +The entire module definition is combined in a struct +PyModuleDef:: + + struct PyModuleDef{ + PyModuleDef_Base m_base; /* To be filled out by the interpreter */ + Py_ssize_t m_size; /* Size of per-module data */ + PyMethodDef *m_methods; + inquiry m_reload; + traverseproc m_traverse; + inquiry m_clear; + freefunc m_free; + }; + +Creation of a module is changed to expect an optional +PyModuleDef*. The module state will be +null-initialized. + +Each module method with be passed the module object +as the first parameter. To access the module data, +a function:: + + void* PyModule_GetData(PyObject*); + +will be provided. In addition, to lookup a module +more efficiently than going through sys.modules, +a function:: + + PyObject* PyState_FindModule(struct PyModuleDef*); + +will be provided. This lookup function will use an +index located in the m_base field, to find the +module by index, not by name. + +As all Python objects should be controlled through +the Python memory management, usage of "static" +type objects is discouraged, unless the type object +itself has no memory-managed state. To simplify +definition of heap types, a new method:: + + PyTypeObject* PyType_Copy(PyTypeObject*); + +is added. + +Example +======= + +xxmodule.c would be changed to remove the initxx +function, and add the following code instead:: + + struct xxstate{ + PyObject *ErrorObject; + PyObject *Xxo_Type; + }; + + #define xxstate(o) ((struct xxstate*)PyModule_GetState(o)) + + static int xx_traverse(PyObject *m, visitproc v, + void *arg) + { + Py_VISIT(xxstate(m)->ErrorObject); + Py_VISIT(xxstate(m)->Xxo_Type); + return 0; + } + + static int xx_clear(PyObject *m) + { + Py_CLEAR(xxstate(m)->ErrorObject); + Py_CLEAR(xxstate(m)->Xxo_Type); + return 0; + } + + static struct PyModuleDef xxmodule = { + {}, /* m_base */ + sizeof(struct xxstate), + &xx_methods, + 0, /* m_reload */ + xx_traverse, + xx_clear, + 0, /* m_free - not needed, since all is done in m_clear */ + } + + PyObject* + PyInit_xx() + { + PyObject *res = PyModule_New("xx", &xxmodule); + if (!res) return NULL; + xxstate(res)->ErrorObject = PyErr_NewException("xx.error, NULL, NULL); + if (!xxstate(res)->ErrorObject) { + Py_DECREF(res); + return NULL; + } + xxstate(res)->XxoType = PyType_Copy(&Xxo_Type); + if (!xxstate(res)->Xxo_Type) { + Py_DECREF(res); + return NULL; + } + return res; + } + + +Discussion +========== + +Tim Peters reports in [1]_ that PythonLabs considered such a feature +at one point, and lists the following additional hooks which aren't +currently supported in this PEP: + + * when the module object is deleted from sys.modules + + * when Py_Finalize is called + + * when Python exits + + * when the Python DLL is unloaded (Windows only) + + +References +========== + +.. [1] Tim Peters, reporting earlier conversation about such a feature + http://mail.python.org/pipermail/python-3000/2006-April/000726.html + + +Copyright +========= + +This document has been placed in the public domain. + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End:

1 0

buildbot warnings in amd64 gentoo trunk
by buildbot＠python.org April 27, 2007

April 27, 2007

The Buildbot has detected a new failure of amd64 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%2520gentoo%2520trunk/builds/19… Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: neal.norwitz Build had warnings: warnings test Excerpt from the test logfile: Traceback (most recent call last): File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/threading.py", line 460, in __bootstrap self.run() File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/test/test_socketserver.py", line 93, in run svr.serve_a_few() File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/test/test_socketserver.py", line 35, in serve_a_few self.handle_request() File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/SocketServer.py", line 224, in handle_request self.handle_error(request, client_address) File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/SocketServer.py", line 429, in process_request self.collect_children() File "/home/buildbot/slave/py-build/trunk.norwitz-amd64/build/Lib/SocketServer.py", line 425, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list make: *** [buildbottest] Segmentation fault (core dumped) sincerely, -The Buildbot

1 0

r54996 - peps/trunk/pep-3118.txt
by georg.brandl April 27, 2007

April 27, 2007

Author: georg.brandl Date: Fri Apr 27 08:58:33 2007 New Revision: 54996 Modified: peps/trunk/pep-3118.txt Log: Some reST sanitizing; change the Authors: header back to "Author:". Modified: peps/trunk/pep-3118.txt ============================================================================== --- peps/trunk/pep-3118.txt (original) +++ peps/trunk/pep-3118.txt Fri Apr 27 08:58:33 2007 @@ -2,7 +2,7 @@ Title: Revising the buffer protocol Version: $Revision$ Last-Modified: $Date$ -Authors: Travis Oliphant <oliphant(a)ee.byu.edu>, Carl Banks <pythondev(a)aerojockey.com> +Author: Travis Oliphant <oliphant(a)ee.byu.edu>, Carl Banks <pythondev(a)aerojockey.com> Status: Draft Type: Standards Track Content-Type: text/x-rst @@ -12,7 +12,7 @@ Abstract ======== -This PEP proposes re-designing the buffer interface (PyBufferProcs +This PEP proposes re-designing the buffer interface (``PyBufferProcs`` function pointers) to improve the way Python allows memory sharing in Python 3.0 @@ -87,7 +87,7 @@ libraries and because it is so simple it makes sense to support memory sharing using this model. The PIL memory model is sometimes used in C-code where a 2-d array can be then accessed using double - pointer indirection: e.g. image[i][j]. + pointer indirection: e.g. ``image[i][j]``. The buffer interface should allow the object to export either of these memory models. Consumers are free to either require contiguous memory @@ -139,26 +139,23 @@ to use the provided C-API to obtain a chunk of memory. -Change the PyBufferProcs structure to - -:: +Change the ``PyBufferProcs`` structure to :: typedef struct { getbufferproc bf_getbuffer; releasebufferproc bf_releasebuffer; - } - + } PyBufferProcs; :: typedef int (*getbufferproc)(PyObject *obj, PyBuffer *view, int flags) -This function returns 0 on success and -1 on failure (and raises an +This function returns ``0`` on success and ``-1`` on failure (and raises an error). The first variable is the "exporting" object. The second -argument is the address to a bufferinfo structure. If view is NULL, +argument is the address to a bufferinfo structure. If view is ``NULL``, then no information is returned but a lock on the memory is still obtained. In this case, the corresponding releasebuffer should also -be called with NULL. +be called with ``NULL``. The third argument indicates what kind of buffer the consumer is prepared to deal with and therefore what kind of buffer the exporter @@ -170,7 +167,7 @@ In addition, some exporters may not be able to share memory in every possible way and may need to raise errors to signal to some consumers that something is just not possible. These errors should be -PyErr_BufferError unless there is another error that is actually +``PyErr_BufferError`` unless there is another error that is actually causing the problem. The exporter can use flags information to simplify how much of the PyBuffer structure is filled in with non-default values and/or raise an error if the object can't support a @@ -183,10 +180,10 @@ segment, while others indicate to the exporter what kind of information the consumer can deal with. If certain information is not asked for by the consumer, but the exporter cannot share its memory -without that information, then a PyErr_BufferError should be raised. +without that information, then a ``PyErr_BufferError`` should be raised. -PyBUF_SIMPLE +``PyBUF_SIMPLE`` This is the default flag state (0). The returned buffer may or may not have writeable memory. The format will be assumed to be @@ -194,12 +191,12 @@ needs to be \|'d to the others. The exporter will raise an error if it cannot provide such a contiguous buffer of bytes. -PyBUF_REQ_WRITEABLE +``PyBUF_REQ_WRITEABLE`` The returned buffer must be writeable. If it is not writeable, then raise an error. -PyBUF_REQ_LOCKDATA +``PyBUF_REQ_LOCKDATA`` The returned buffer must be readonly. If the object is already read-only or it can make its memory read-only (and there are no @@ -207,28 +204,28 @@ buffer information. If the object does not have read-only memory (or cannot make it read-only), then an error should be raised. -PyBUF_REQ_FORMAT +``PyBUF_REQ_FORMAT`` The returned buffer must have true format information if this flag is provided. This would be used when the consumer is going to be checking for what 'kind' of data is actually stored. An exporter should always be able to provide this information if requested. If format is not explicitly requested then the format must be returned - as NULL (which means "B") + as ``NULL`` (which means "B") -PyBUF_REQ_ALIGNED (implies PyBUF_REQ_FORMAT) +``PyBUF_REQ_ALIGNED`` (implies ``PyBUF_REQ_FORMAT``) The returned buffer must have all (primitive data-type entries) aligned as the compiler would align them -PyBUF_ALW_ND +``PyBUF_ALW_ND`` The returned buffer must provide shape information. The memory will be assumed C-style contiguous (last dimension varies the fastest). The exporter may raise an error if it cannot provide this kind of contiguous buffer. -PyBUF_ALW_STRIDES (implies PyBUF_ALW_ND) +``PyBUF_ALW_STRIDES`` (implies ``PyBUF_ALW_ND``) The returned buffer must provide strides information. This would be used when the consumer can handle strided, discontiguous arrays. @@ -236,9 +233,9 @@ The exporter may raise an error if cannot provide a strided-only representation of the data (i.e. without the suboffsets). -PyBUF_REQ_C_CONTIGUOUS -PyBUF_REQ_F_CONTIGUOUS -PyBUF_REQ_ANY_CONTIGUOUS +| ``PyBUF_REQ_C_CONTIGUOUS`` +| ``PyBUF_REQ_F_CONTIGUOUS`` +| ``PyBUF_REQ_ANY_CONTIGUOUS`` These flags indicate that the returned buffer must be respectively, C-contiguous (last dimension varies the fastest), Fortran @@ -247,7 +244,7 @@ strides buffer info structure will be filled in correctly. -PyBUF_ALW_INDIRECT (implies PyBUF_ALW_STRIDES) +``PyBUF_ALW_INDIRECT`` (implies ``PyBUF_ALW_STRIDES``) The returned buffer must have suboffsets information. This would be used when the consumer can handle indirect array referencing @@ -258,34 +255,34 @@ Multi-dimensional (but contiguous) - PyBUF_CONTIG (PyBUF_ALW_ND | PyBUF_REQ_WRITEABLE | PyBUF_REQ_ALIGNED) - PyBUF_CONTIG_RO (PyBUF_ALW_ND | PyBUF_REQ_ALIGNED) - PyBUF_CONTIG_LCK (PyBUF_ALW_ND | PyBUF_REQ_LOCKDATA | PyBUF_REQ_ALIGNED) + | ``PyBUF_CONTIG`` (``PyBUF_ALW_ND | PyBUF_REQ_WRITEABLE | PyBUF_REQ_ALIGNED``) + | ``PyBUF_CONTIG_RO`` (``PyBUF_ALW_ND | PyBUF_REQ_ALIGNED``) + | ``PyBUF_CONTIG_LCK`` (``PyBUF_ALW_ND | PyBUF_REQ_LOCKDATA | PyBUF_REQ_ALIGNED``) Multi-dimensional using strides but aligned - PyBUF_STRIDED (PyBUF_ALW_STRIDES | PyBUF_REQ_WRITEABLE | PyBUF_REQ_ALIGNED) - PyBUF_STRIDED_RO (PyBUF_ALW_STRIDES | PyBUF_REQ_ALIGNED) - PyBUF_STRIDED_LCK (PyBUF_ALW_STRIDES | PyBUF_REQ_LOCKDATA | PyBUF_REQ_ALIGNED) + | ``PyBUF_STRIDED`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_WRITEABLE | PyBUF_REQ_ALIGNED``) + | ``PyBUF_STRIDED_RO`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_ALIGNED``) + | ``PyBUF_STRIDED_LCK`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_LOCKDATA | PyBUF_REQ_ALIGNED``) Multi-dimensional using strides and not necessarily aligned - PyBUF_RECORDS (PyBUF_ALW_STRIDES | PyBUF_REQ_WRITEABLE | PyBUF_REQ_FORMAT) - PyBUF_RECORDS_RO (PyBUF_ALW_STRIDES | PyBUF_REQ_FORMAT) - PyBUF_RECORDS_LCK (PyBUF_ALW_STRIDES | PyBUF_REQ_LOCKDATA | PyBUF_REQ_FORMAT) + | ``PyBUF_RECORDS`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_WRITEABLE | PyBUF_REQ_FORMAT``) + | ``PyBUF_RECORDS_RO`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_FORMAT``) + | ``PyBUF_RECORDS_LCK`` (``PyBUF_ALW_STRIDES | PyBUF_REQ_LOCKDATA | PyBUF_REQ_FORMAT``) Multi-dimensional using sub-offsets - PyBUF_FULL (PyBUF_ALW_INDIRECT | PyBUF_REQ_WRITEABLE | PyBUF_REQ_FORMAT) - PyBUF_FULL_RO (PyBUF_ALW_INDIRECT | PyBUF_REQ_FORMAT) - PyBUF_FULL_LCK (PyBUF_ALW_INDIRECT | PyBUF_REQ_LOCKDATA | PyBUF_REQ_FORMAT) + | ``PyBUF_FULL`` (``PyBUF_ALW_INDIRECT | PyBUF_REQ_WRITEABLE | PyBUF_REQ_FORMAT``) + | ``PyBUF_FULL_RO`` (``PyBUF_ALW_INDIRECT | PyBUF_REQ_FORMAT``) + | ``PyBUF_FULL_LCK`` (``PyBUF_ALW_INDIRECT | PyBUF_REQ_LOCKDATA | PyBUF_REQ_FORMAT``) Thus, the consumer simply wanting a contiguous chunk of bytes from -the object would use PyBUF_SIMPLE, while a consumer that understands -how to make use of the most complicated cases could use PyBUF_FULL +the object would use ``PyBUF_SIMPLE``, while a consumer that understands +how to make use of the most complicated cases could use ``PyBUF_FULL``. The format information is only guaranteed to be non-NULL if -PyBUF_REQ_FORMAT is in the flag argument, otherwise it is expected the +``PyBUF_REQ_FORMAT`` is in the flag argument, otherwise it is expected the consumer will assume unsigned bytes. There is a C-API that simple exporting objects can use to fill-in the @@ -319,15 +316,15 @@ The members of the bufferinfo structure are: -buf +``buf`` a pointer to the start of the memory for the object -len +``len`` the total bytes of memory the object uses. This should be the same as the product of the shape array multiplied by the number of bytes per item of memory. -readonly +``readonly`` an integer variable to hold whether or not the memory is readonly. 1 means the memory is readonly, zero means the memory is writeable, and -1 means the memory was "locked" (changed from @@ -335,33 +332,33 @@ and therefore should be unlocked when this PyBuffer structure is "released" (this is supported only by some exporters). -format +``format`` a NULL-terminated format-string (following the struct-style syntax including extensions) indicating what is in each element of memory. The number of elements is len / itemsize, where itemsize is the number of bytes implied by the format. This can be NULL which implies standard unsigned bytes ("B"). -ndims +``ndims`` a variable storing the number of dimensions the memory represents. Must be >=0. A value of 0 means that shape and strides and suboffsets - must be NULL (i.e. the memory represents a scalar). + must be ``NULL`` (i.e. the memory represents a scalar). -shape +``shape`` an array of ``Py_ssize_t`` of length ``ndims`` indicating the shape of the memory as an N-D array. Note that ``((*shape)[0] * ... * (*shape)[ndims-1])*itemsize = len``. If ndims is 0 (indicating - a scalar), then this must be NULL. + a scalar), then this must be ``NULL``. -strides +``strides`` address of a ``Py_ssize_t*`` variable that will be filled with a - pointer to an array of ``Py_ssize_t`` of length ``ndims`` (or NULL - if ndims is 0). indicating the number of bytes to skip to get to + pointer to an array of ``Py_ssize_t`` of length ``ndims`` (or ``NULL`` + if ``ndims`` is 0). indicating the number of bytes to skip to get to the next element in each dimension. If this is not requested by - the caller (PyBUF_ALW_STRIDES is not set), then this should be set + the caller (``PyBUF_ALW_STRIDES`` is not set), then this should be set to NULL which indicates a C-style contiguous array. -suboffsets +``suboffsets`` address of a ``Py_ssize_t *`` variable that will be filled with a pointer to an array of ``Py_ssize_t`` of length ``*ndims``. If these suboffset numbers are >=0, then the value stored along the @@ -374,14 +371,14 @@ For clarity, here is a function that returns a pointer to the element in an N-D array pointed to by an N-dimesional index when - there are both non-NULL strides and suboffsets.:: + there are both non-NULL strides and suboffsets:: - void* get_item_pointer(int ndim, void* buf, Py_ssize_t* strides, - Py_ssize_t* suboffsets, Py_ssize_t *indices) { - char* pointer = (char*)buf; + void *get_item_pointer(int ndim, void *buf, Py_ssize_t *strides, + Py_ssize_t *suboffsets, Py_ssize_t *indices) { + char *pointer = (char*)buf; int i; for (i = 0; i < ndim; i++) { - pointer += strides[i]*indices[i]; + pointer += strides[i] * indices[i]; if (suboffsets[i] >=0 ) { pointer = *((char**)pointer) + suboffsets[i]; } @@ -395,15 +392,15 @@ the location of the starting pointer directly (i.e. buf would be modified). -itemsize +``itemsize`` This is a storage for the itemsize of each element of the shared memory. It is strictly un-necessary as it can be obtained using - PyBuffer_SizeFromFormat, however an exporter may know this + ``PyBuffer_SizeFromFormat``, however an exporter may know this information without parsing the format string and it is necessary to know the itemsize for proper interpretation of striding. Therefore, storing it is more convenient and faster. -internal +``internal`` This is for use internally by the exporting object. For example, this might be re-cast as an integer by the exporter and used to store flags about whether or not the shape, strides, and suboffsets @@ -468,7 +465,9 @@ This is a C-API version of the getbuffer function call. It checks to make sure object has the required function pointer and issues the call. Returns -1 and raises an error on failure and returns 0 on -success.:: +success. + +:: int PyObject_ReleaseBuffer(PyObject *obj, PyBuffer *view) @@ -486,9 +485,7 @@ A memory-view object is an extended buffer object that could replace the buffer object (but doesn't have to as that could be kept as a -simple 1-d memory-view object). It's C-structure is - -:: +simple 1-d memory-view object). Its C-structure is :: typedef struct { PyObject_HEAD @@ -521,29 +518,29 @@ The Python name will be -__builtin__.memory +``__builtin__.memory`` Methods: -| lock -| unlock -| __getitem__ (will support multi-dimensional slicing) -| __setitem__ (will support multi-dimensional slicing) -| tobytes (obtain a bytes-object of everything in the memory). -| tolist (obtain a "nested" list of the memory. Everything - is interpreted into standard Python objects - as the struct module unpack would do). - -Attributes (taken from the memory of the base object) - - format - itemsize - shape - strides - suboffsets - size - readonly - ndim +| ``lock`` +| ``unlock`` +| ``__getitem__`` (will support multi-dimensional slicing) +| ``__setitem__`` (will support multi-dimensional slicing) +| ``tobytes`` (obtain a bytes-object of everything in the memory). +| ``tolist`` (obtain a "nested" list of the memory. Everything + is interpreted into standard Python objects + as the struct module unpack would do). + +Attributes (taken from the memory of the base object): + +* ``format`` +* ``itemsize`` +* ``shape`` +* ``strides`` +* ``suboffsets`` +* ``size`` +* ``readonly`` +* ``ndim`` :: @@ -594,13 +591,15 @@ :: - int PyBuffer_IsContiguous(PyBuffer *view, char fortran); + int PyBuffer_IsContiguous(PyBuffer *view, char fortran) Return 1 if the memory defined by the view object is C-style (fortran = 'C') or Fortran-style (fortran = 'F') contiguous or either one -(fortran = 'A'). Return 0 otherwise.:: +(fortran = 'A'). Return 0 otherwise. + +:: - int PyBuffer_IsAligned(PyBuffer *view); + int PyBuffer_IsAligned(PyBuffer *view) Return 1 if the memory at all elements of the array implied by the view object is aligned @@ -613,7 +612,9 @@ Fill the strides array with byte-strides of a contiguous (C-style if fortran is 0 or Fortran-style if fortran is 1) array of the given -shape with the given number of bytes per element.:: +shape with the given number of bytes per element. + +:: int PyBuffer_FillInfo(PyBuffer *view, void *buf, Py_ssize_t len, int readonly, int infoflags) @@ -623,7 +624,8 @@ given length. Returns 0 on success and -1 (with raising an error) on error. -:: +:: + PyErr_BufferError A new error object for returning buffer errors which arise because an @@ -638,7 +640,7 @@ The struct string-syntax is missing some characters to fully implement data-format descriptions already available elsewhere (in ctypes and NumPy for example). The Python 2.5 specification is -at http://docs.python.org/lib/module-struct.html +at http://docs.python.org/lib/module-struct.html. Here are the proposed additions: @@ -682,11 +684,11 @@ previously-specified endian string is in force until changed. The default endian is '@' which means native data-types and alignment. If un-aligned, native data-types are requested, then the endian -specification is '^'. +specification is '^'. According to the struct-module, a number can preceed a character code to specify how many of that type there are. The -(k1,k2,...,kn) extension also allows specifying if the data is +``(k1,k2,...,kn)`` extension also allows specifying if the data is supposed to be viewed as a (C-style contiguous, last-dimension varies the fastest) multi-dimensional array of a particular format. @@ -702,15 +704,15 @@ <named> is the constructor for a named-tuple (not-specified yet). float - 'f' <--> Python float + ``'f'`` <--> Python float complex double - 'Zd' <--> Python complex + ``'Zd'`` <--> Python complex RGB Pixel data - 'BBB' <--> (int, int, int) - 'B:r: B:g: B:b:' <--> <named>((int, int, int), ('r','g','b')) + ``'BBB'`` <--> (int, int, int) + ``'B:r: B:g: B:b:'`` <--> <named>((int, int, int), ('r','g','b')) Mixed endian (weird but possible) - '>i:big: <i:little:' <--> <named>((int, int), ('big', 'little')) + ``'>i:big: <i:little:'`` <--> <named>((int, int), ('big', 'little')) Nested structure :: @@ -802,8 +804,9 @@ call more difficult. The flags variable allows the same ability of consumers to be "simple" in how they call the protocol. + Code -======== +==== The authors of the PEP promise to contribute and maintain the code for this proposal but will welcome any help. @@ -812,7 +815,7 @@ Examples -========= +======== Ex. 1 ----------- @@ -834,8 +837,8 @@ Py_ssize_t view_count; }; -"lines" points to malloced 1-D array of (struct rgba*). Each pointer -in THAT block points to a seperately malloced array of (struct rgba). +"lines" points to malloced 1-D array of ``(struct rgba*)``. Each pointer +in THAT block points to a seperately malloced array of ``(struct rgba)``. In order to access, say, the red value of the pixel at x=30, y=50, you'd use "lines[50][30].r". @@ -957,5 +960,5 @@ Copyright ========= -This PEP is placed in the public domain +This PEP is placed in the public domain.

1 0

r54994 - peps/trunk/pep-3120.txt
by martin.v.loewis April 27, 2007

April 27, 2007

Author: martin.v.loewis Date: Fri Apr 27 08:34:37 2007 New Revision: 54994 Modified: peps/trunk/pep-3120.txt Log: Remove extra spaces. Modified: peps/trunk/pep-3120.txt ============================================================================== --- peps/trunk/pep-3120.txt (original) +++ peps/trunk/pep-3120.txt Fri Apr 27 08:34:37 2007 @@ -1,7 +1,7 @@ PEP: 3120 Title: Using UTF-8 as the default source encoding -Version: $Revision $ -Last-Modified: $Date $ +Version: $Revision$ +Last-Modified: $Date$ Author: Martin v. Löwis <martin(a)v.loewis.de> Status: Draft Type: Standards Track

1 0