[Python-checkins] peps: Add some comments and acknowledgements
antoine.pitrou
python-checkins at python.org
Sat Apr 27 13:24:54 CEST 2013
http://hg.python.org/peps/rev/d9be356b12a8
changeset: 4865:d9be356b12a8
user: Antoine Pitrou <solipsis at pitrou.net>
date: Sat Apr 27 13:24:45 2013 +0200
summary:
Add some comments and acknowledgements
files:
pep-3154.txt | 50 ++++++++++++++++++++++++++++++++-------
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/pep-3154.txt b/pep-3154.txt
--- a/pep-3154.txt
+++ b/pep-3154.txt
@@ -7,8 +7,9 @@
Type: Standards Track
Content-Type: text/x-rst
Created: 2011-08-11
-Python-Version: 3.3
+Python-Version: 3.4
Post-History:
+ http://mail.python.org/pipermail/python-dev/2011-August/112821.html
Resolution: TBD
@@ -36,10 +37,10 @@
object). The opportunity was not taken at the time to improve the
protocol in other ways.
-This PEP is an attempt to foster a number of small incremental
-improvements in a future new protocol version. The PEP process is
-used in order to gather as many improvements as possible, because the
-introduction of a new protocol version should be a rare occurrence.
+This PEP is an attempt to foster a number of incremental improvements
+in a new pickle protocol version. The PEP process is used in order to
+gather as many improvements as possible, because the introduction of a
+new pickle protocol should be a rare occurrence.
Proposed changes
@@ -74,11 +75,15 @@
pickles, and the unpickler refuses them. Also, there is no "last frame"
marker. The last frame is simply the one which ends with a STOP opcode.
+A well-written C implementation doesn't need additional memory copies
+for the framing layer, preserving general (un)pickling efficiency.
+
.. note::
- How the pickler partitions the pickle stream into frames is an
- implementation detail. "Closing" a frame as soon as it reaches
- ~64 KiB should be ok for both performance and pickle size overhead.
+ How the pickler decides to partition the pickle stream into frames is an
+ implementation detail. For example, "closing" a frame as soon as it
+ reaches ~64 KiB is a reasonable choice for both performance and pickle
+ size overhead.
Binary encoding for all opcodes
-------------------------------
@@ -138,10 +143,31 @@
would make many pickles smaller.
+Alternative ideas
+=================
+
+Prefetching
+-----------
+
+Serhiy Storchaka suggested to replace framing with a special PREFETCH
+opcode (with a 2- or 4-bytes argument) to declare known pickle chunks
+explicitly. Large data may be pickled outside such chunks. A naïve
+unpickler should be able to skip the PREFETCH opcode and still decode
+pickles properly, but good error handling would require checking that
+the PREFETCH length falls on an opcode boundary.
+
+
Acknowledgments
===============
-(...)
+In alphabetic order:
+
+* Alexandre Vassalotti, for starting the second PEP 3154 implementation [6]_
+
+* Serhiy Storchaka, for discussing the framing proposal [6]_
+
+* Stefan Mihaila, for starting the first PEP 3154 implementation as a
+ Google Summer of Code project mentored by Alexandre Vassalotti [7]_.
References
@@ -162,6 +188,12 @@
.. [5] Lib/multiprocessing/forking.py:
http://hg.python.org/cpython/file/baea9f5f973c/Lib/multiprocessing/forking.py#l54
+.. [6] Implement PEP 3154, by Alexandre Vassalotti
+ http://bugs.python.org/issue17810
+
+.. [7] Implement PEP 3154, by Stefan Mihaila
+ http://bugs.python.org/issue15642
+
Copyright
=========
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list