[Python-Dev] Accepting PEP 3154 for 3.4?

Tim Peters tim.peters at gmail.com
Tue Nov 19 20:22:52 CET 2013


[Guido]
> So using an opcode for framing is out? (Sorry, I've lost track of the
> back-and-forth.)

It was never in ;-)  I'd *prefer* one, but not enough to try to block
the PEP.  As is, framing is done at a "lower level" than opcode
decoding.  I fear this is brittle, for all the usual "explicit is
better than implicit" kinds of reasons.  The only way now to know that
you're looking at a frame size is to keep a running count of bytes
processed and realize you've reached a byte offset where a frame size
"is expected".

With an opcode, framing could also be optional (whenever desired),
because frame sizes would be _explicitly_ marked in the byte stream
Then the framing overhead for small pickles could drop to 0 bytes
(instead of the current 8, or 1 thru 9 under various other schemes).

Ideal would be an explicit framing opcode combined with
variable-length size encoding.  That would never require more bytes
than the current scheme, and 'almost always" require fewer.  But even
I don't think it's of much value to chop a few bytes off every 64KB of
pickle ;-)


More information about the Python-Dev mailing list