On Tue, 19 Nov 2013 15:41:51 -0600 Tim Peters <tim.pet...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
