PEP 574 additions (#621)

pep-0574.rst

@@ -7,7 +7,7 @@ Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 23-Mar-2018
-Post-History:
+Post-History: 28-Mar-2018
 Resolution:
 
 
@@ -187,6 +187,8 @@ takes a single PEP 3118-compatible object [#pep-3118]_.  ``PickleBuffer``
 objects themselves support the buffer protocol, so consumers can
 call ``memoryview(...)`` on them to get additional information
 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
 PickleBuffer objects:
@@ -203,7 +205,12 @@ PickleBuffer objects:
 ``const Py_buffer *PyPickleBuffer_GetBuffer(PyObject *picklebuf)``
 
    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
 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
   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
 ============