[Python-Dev] Accepting PEP 3154 for 3.4? (original) (raw)

Tim Peters tim.peters at gmail.com
Thu Nov 21 02:23:18 CET 2013

[Alexandre Vassalotti]

Looking at the different options available to us:

1A. Mandatory framing (+) Allows the internal buffering layer of the Unpickler to rely on the presence of framing to simplify its implementation. (-) Forces all implementations of pickle to include support for framing if they want to use the new protocol. (-) Cannot be removed from future versions of the Unpickler without breaking protocols which mandates framing. 1B. Optional framing (+) Could allow optimizations to disable framing if beneficial (e.g., when pickling to and unpickling from a string).

Or to slash the size of small pickles (an 8-byte size field can be more than half the total pickle size).

2A. With explicit FRAME opcode (+) Makes optional framing simpler to implement. (+) Makes variable-length encoding of the frame size simpler to implement. (+) Makes framing visible to pickletools.

(+) Adds (a little) redundancy for sanity checking.

(-) Adds an extra byte of overhead to each frames. 2B. No opcode

3A. With fixed 8-bytes headers (+) Is simple to implement (-) Adds overhead to small pickles. 3B. With variable-length headers (-) Requires Pickler implemention to do extra data copies when pickling to strings. 4A. Framing baked-in the pickle protocol (+) Enables faster implementations 4B. Framing through a specialized I/O buffering layer (+) Could be reused by other modules I may change my mind as I work on the implementation, but at least for now, I think the combination of 1B, 2A, 3A, 4A will be a reasonable compromise here.

At this time I'd make the same choices, so don't expect an argument from me ;-) Thank you!

More information about the Python-Dev mailing list