iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 574 additions (#621)

This commit is contained in:
Antoine Pitrou 2018-04-13 18:16:58 +02:00 committed by GitHub
parent cf7e061167
commit 61cb444e6d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0574.rst
View File

@ -7,7 +7,7 @@ Status: Draft
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 23-Mar-2018 Created: 23-Mar-2018
Post-History: Post-History: 28-Mar-2018
Resolution: Resolution:
@ -187,6 +187,8 @@ takes a single PEP 3118-compatible object [#pep-3118]_. ``PickleBuffer``
objects themselves support the buffer protocol, so consumers can objects themselves support the buffer protocol, so consumers can
call ``memoryview(...)`` on them to get additional information call ``memoryview(...)`` on them to get additional information
about the underlying buffer (such as the original type, shape, etc.). about the underlying buffer (such as the original type, shape, etc.).
In addition, ``PickleBuffer`` objects can be explicitly released using
their ``release()`` method.
On the C side, a simple API will be provided to create and inspect On the C side, a simple API will be provided to create and inspect
PickleBuffer objects: PickleBuffer objects:
@ -203,7 +205,12 @@ PickleBuffer objects:
``const Py_buffer *PyPickleBuffer_GetBuffer(PyObject *picklebuf)`` ``const Py_buffer *PyPickleBuffer_GetBuffer(PyObject *picklebuf)``
Return a pointer to the internal ``Py_buffer`` owned by the ``PickleBuffer`` Return a pointer to the internal ``Py_buffer`` owned by the ``PickleBuffer``
instance. instance. An exception is raised if the buffer is released.
``int PyPickleBuffer_Release(PyObject *picklebuf)``
Release the ``PickleBuffer`` instance's underlying buffer.
``PickleBuffer`` can wrap any kind of buffer, including non-contiguous ``PickleBuffer`` can wrap any kind of buffer, including non-contiguous
buffers. It's up to consumers to decide how best to handle different kinds buffers. It's up to consumers to decide how best to handle different kinds
@ -400,6 +407,16 @@ Should ``buffer_callback`` take a single buffers or a sequence of buffers?
* Taking a sequence of buffers is potentially more efficient by reducing * Taking a sequence of buffers is potentially more efficient by reducing
function call overhead. function call overhead.
Should it be allowed to serialize a ``PickleBuffer`` in protocol 4 and earlier?
It would simply be serialized as a ``bytes`` object (if read-only) or
``bytearray`` (if writable).
* It can make implementing ``__reduce__`` simpler.
* Serializing a ``bytearray`` in protocol 4 makes a supplementary memory
copy when ``bytearray.__reduce_ex__`` returns a ``bytes`` object. This
is a performance regression that may be overlooked by ``__reduce__``
implementors.
Related work Related work
============ ============