[Python-Dev] Accepting PEP 3154 for 3.4?

[Antoine Pitrou]

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.