Fix formatting problems.
This commit is contained in:
parent
396908697c
commit
e8beb1ae2f
36
pep-3118.txt
36
pep-3118.txt
|
@ -1,4 +1,3 @@
|
|||
|
||||
PEP: 3118
|
||||
Title: Revising the buffer protocol
|
||||
Version: $Revision$
|
||||
|
@ -192,7 +191,7 @@ 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
|
||||
unsigned bytes . This is a "stand-alone" flag constant. It never
|
||||
needs to be |'d to the others. The exporter will raise an error if
|
||||
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
|
||||
|
@ -469,9 +468,8 @@ Return 1 if the getbuffer function is available otherwise 0.
|
|||
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)
|
||||
|
||||
This is a C-API version of the releasebuffer function call. It checks
|
||||
|
@ -527,12 +525,12 @@ __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
|
||||
| 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).
|
||||
|
||||
|
@ -600,9 +598,8 @@ their work.
|
|||
|
||||
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);
|
||||
|
||||
Return 1 if the memory at all elements of the array implied by the
|
||||
|
@ -616,9 +613,8 @@ view object is aligned
|
|||
|
||||
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)
|
||||
|
||||
|
@ -821,9 +817,7 @@ Examples
|
|||
Ex. 1
|
||||
-----------
|
||||
|
||||
This example shows how an image object that uses contiguous lines might expose its buffer.::
|
||||
|
||||
::
|
||||
This example shows how an image object that uses contiguous lines might expose its buffer::
|
||||
|
||||
struct rgba {
|
||||
unsigned char r, g, b, a;
|
||||
|
@ -847,8 +841,6 @@ In order to access, say, the red value of the pixel at x=30, y=50, you'd use "li
|
|||
|
||||
So what does ImageObject's getbuffer do? Leaving error checking out::
|
||||
|
||||
::
|
||||
|
||||
int Image_getbuffer(PyObject *self, PyBuffer *view, int flags) {
|
||||
|
||||
static Py_ssize_t suboffsets[2] = { -1, 0 };
|
||||
|
@ -899,9 +891,9 @@ alive) would do that.
|
|||
return PyObject_FillBufferInfo(view, buf, len, readonly, flags);
|
||||
}
|
||||
|
||||
/* No releasebuffer is necessary because the memory will never
|
||||
be re-allocated so the locking mechanism is not needed
|
||||
*/
|
||||
/* No releasebuffer is necessary because the memory will never
|
||||
be re-allocated so the locking mechanism is not needed
|
||||
*/
|
||||
|
||||
Ex. 3
|
||||
-----------
|
||||
|
|
Loading…
Reference in New Issue