[Python-Dev] Accepting PEP 3154 for 3.4?
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:
> >> ...
> >> 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.
> > 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
> > 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.
More information about the Python-Dev