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

Tim Peters tim.peters at gmail.com
Tue Nov 19 22:41:51 CET 2013

[Tim]

... But if some other implementation of unpickling didn't give a hoot about framing, having an explicit opcode means that implementation could ignore the whole scheme very easily: just implement the FRAME opcode in its opcode-decoding loop to consume the FRAME argument, ignore it, and move on. As-is, all other implementations have to know everything about the buffering scheme because it's all implicit low-level magic.

[Antoine]

Ahah, ok, I see where you're going. But how many other implementations of unpickling are there?

That's something you should have researched when writing the PEP ;-) How many implementations of Python aren't CPython? That's probably the answer. I'm not an expert on that, but there's more than one.

Initially, all I desperately ;-) want changed here is for the buffering layer, on the writing end, to write 9 bytes instead of 8 (1 new one for a FRAME opcode), and on the reading end to consume 9 bytes instead of 8 (extra credit if it checked the first byte to verify it really is a FRAME opcode - there's nothing wrong with sanity checks).

Then it becomes possible to optimize "small pickles" later (in the sense of not bothering to frame them at all).

So the CPython unpickler must be able to work with and without framing by detecting the FRAME opcode?

Not at first, no. At first the buffering layer could raise an exception if there's no FRAME opcode when it expected one. Or just read up garbage bytes and assume it's a frame size, which is effectively what it's doing now anyway ;-)

Otherwise the "later optimization" can't work.

Right. If reducing framing overhead to "nothing" for small pickles turns out to be sufficiently desirable, then the buffering layer would need to learn how to turn itself off in the absence of a FRAME opcode immediately following the current frame. Perhaps the opcode decoding loop would also need to learn how to turn the buffering layer back on again too (next time a FRAME opcode showed up). Sounds annoying, but not impossible.

More information about the Python-Dev mailing list