[Python-Dev] Accepting PEP 3154 for 3.4?
tim.peters at gmail.com
Thu Nov 21 02:23:18 CET 2013
> 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
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