diff options
author | Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> | 2009-04-26 21:06:15 (GMT) |
---|---|---|
committer | Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> | 2009-04-26 21:06:15 (GMT) |
commit | bd87552a3453539f2a70f2b7c50c2980a436c567 (patch) | |
tree | 4b505dd36616aa61eb6e67c6fa965e3aee07b28d /Doc/c-api/buffer.rst | |
parent | 939c178379c6d979f49a083a6f3cbabf7b10b479 (diff) | |
download | cpython-bd87552a3453539f2a70f2b7c50c2980a436c567.zip cpython-bd87552a3453539f2a70f2b7c50c2980a436c567.tar.gz cpython-bd87552a3453539f2a70f2b7c50c2980a436c567.tar.bz2 |
Merged revisions 71898-71900,71910,71914-71919 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r71898 | jeroen.ruigrok | 2009-04-25 16:24:30 +0200 (za, 25 apr 2009) | 2 lines
Reformat prior to editing.
........
r71899 | jeroen.ruigrok | 2009-04-25 16:27:00 +0200 (za, 25 apr 2009) | 3 lines
The type for ppos has been Py_ssize_t since 2.5, reflect this in the
documentation.
........
r71900 | jeroen.ruigrok | 2009-04-25 16:28:02 +0200 (za, 25 apr 2009) | 2 lines
Reformat paragraph.
........
r71910 | jeroen.ruigrok | 2009-04-25 19:59:03 +0200 (za, 25 apr 2009) | 4 lines
Issue #4129: Belatedly document which C API functions had their argument(s) or
return type changed from int or int * to Py_ssize_t or Py_ssize_t * as this
might cause problems on 64-bit platforms.
........
r71914 | jeroen.ruigrok | 2009-04-25 20:31:20 +0200 (za, 25 apr 2009) | 2 lines
Reformat prior to editing.
........
r71915 | jeroen.ruigrok | 2009-04-25 20:46:03 +0200 (za, 25 apr 2009) | 2 lines
Issue #4129: Document more int -> Py_ssize_t changes.
........
r71916 | jeroen.ruigrok | 2009-04-25 20:53:48 +0200 (za, 25 apr 2009) | 2 lines
Reformat prior to editing.
........
r71917 | jeroen.ruigrok | 2009-04-25 20:57:32 +0200 (za, 25 apr 2009) | 2 lines
Reference to an int type, whereas it's a Py_ssize_t as the synopsis states.
........
r71918 | jeroen.ruigrok | 2009-04-25 21:04:15 +0200 (za, 25 apr 2009) | 2 lines
Since I edited this file, reformat for future edits.
........
r71919 | jeroen.ruigrok | 2009-04-25 21:10:52 +0200 (za, 25 apr 2009) | 2 lines
Reformat prior to editing.
........
Diffstat (limited to 'Doc/c-api/buffer.rst')
-rw-r--r-- | Doc/c-api/buffer.rst | 60 |
1 files changed, 30 insertions, 30 deletions
diff --git a/Doc/c-api/buffer.rst b/Doc/c-api/buffer.rst index a172e53..a75e450 100644 --- a/Doc/c-api/buffer.rst +++ b/Doc/c-api/buffer.rst @@ -15,8 +15,8 @@ Buffer Objects Python objects implemented in C can export a "buffer interface." These functions can be used by an object to expose its data in a raw, byte-oriented -format. Clients of the object can use the buffer interface to access the object -data directly, without needing to copy it first. +format. Clients of the object can use the buffer interface to access the +object data directly, without needing to copy it first. Two examples of objects that support the buffer interface are bytes and arrays. The bytes object exposes the character contents in the buffer @@ -61,9 +61,9 @@ could be used to pass around structured data in its native, in-memory format. .. cmember:: const char *format :noindex: - A *NULL* terminated string in :mod:`struct` module style syntax giving the - contents of the elements available through the buffer. If this is *NULL*, - ``"B"`` (unsigned bytes) is assumed. + A *NULL* terminated string in :mod:`struct` module style syntax giving + the contents of the elements available through the buffer. If this is + *NULL*, ``"B"`` (unsigned bytes) is assumed. .. cmember:: int ndim @@ -113,11 +113,11 @@ could be used to pass around structured data in its native, in-memory format. .. cmember:: Py_ssize_t itemsize This is a storage for the itemsize (in bytes) of each element of the - shared memory. It is technically un-necessary as it can be obtained using - :cfunc:`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. + shared memory. It is technically un-necessary as it can be obtained + using :cfunc:`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. .. cmember:: void *internal @@ -140,20 +140,20 @@ Buffer related functions .. cfunction:: int PyObject_GetBuffer(PyObject *obj, PyObject *view, int flags) Export *obj* into a :ctype:`Py_buffer`, *view*. These arguments must - never be *NULL*. The *flags* argument is a bit field indicating what kind - of buffer the caller is prepared to deal with and therefore what kind of - buffer the exporter is allowed to return. The buffer interface allows for - complicated memory sharing possibilities, but some caller may not be able - to handle all the complexibity but may want to see if the exporter will - let them take a simpler view to its memory. + never be *NULL*. The *flags* argument is a bit field indicating what + kind of buffer the caller is prepared to deal with and therefore what + kind of buffer the exporter is allowed to return. The buffer interface + allows for complicated memory sharing possibilities, but some caller may + not be able to handle all the complexibity but may want to see if the + exporter will let them take a simpler view to its memory. 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 a :exc:`BufferError` unless - there is another error that is actually causing the problem. The exporter - can use flags information to simplify how much of the :cdata:`Py_buffer` - structure is filled in with non-default values and/or raise an error if - the object can't support a simpler view of its memory. + there is another error that is actually causing the problem. The + exporter can use flags information to simplify how much of the + :cdata:`Py_buffer` structure is filled in with non-default values and/or + raise an error if the object can't support a simpler view of its memory. 0 is returned on success and -1 on error. @@ -264,16 +264,16 @@ Buffer related functions .. cfunction:: int PyObject_CopyToObject(PyObject *obj, void *buf, Py_ssize_t len, char fortran) - Copy *len* bytes of data pointed to by the contiguous chunk of memory pointed - to by *buf* into the buffer exported by obj. The buffer must of course be - writable. Return 0 on success and return -1 and raise an error on failure. - If the object does not have a writable buffer, then an error is raised. If - *fortran* is ``'F'``, then if the object is multi-dimensional, then the data - will be copied into the array in Fortran-style (first dimension varies the - fastest). If *fortran* is ``'C'``, then the data will be copied into the - array in C-style (last dimension varies the fastest). If *fortran* is - ``'A'``, then it does not matter and the copy will be made in whatever way is - more efficient. + Copy *len* bytes of data pointed to by the contiguous chunk of memory + pointed to by *buf* into the buffer exported by obj. The buffer must of + course be writable. Return 0 on success and return -1 and raise an error + on failure. If the object does not have a writable buffer, then an error + is raised. If *fortran* is ``'F'``, then if the object is + multi-dimensional, then the data will be copied into the array in + Fortran-style (first dimension varies the fastest). If *fortran* is + ``'C'``, then the data will be copied into the array in C-style (last + dimension varies the fastest). If *fortran* is ``'A'``, then it does not + matter and the copy will be made in whatever way is more efficient. .. cfunction:: int PyBuffer_IsContiguous(Py_buffer *view, char fortran) |