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

Antoine Pitrou solipsis at pitrou.net
Tue Nov 19 22:54:14 CET 2013

On Tue, 19 Nov 2013 15:41:51 -0600 Tim Peters <tim.peters at gmail.com> wrote:

[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.

But "how many of them use something else than Lib/pickle.py" is the actual question.

> 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.

The problem with "let's make the unpickler more lenient in a later version" is that then you have protocol 4 pickles that won't work with all protocol 4-accepting versions of the pickle module.

Regards

Antoine.

More information about the Python-Dev mailing list