[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