[Python-Dev] Accepting PEP 3154 for 3.4?

[Tim Peters]

[Antoine Pitrou]
> Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> the PEP 3154 implementation - pickle protocol 4.
>
> I think it would be good to get the PEP and the implementation accepted
> for 3.4. As far as I can say, this has been a low-controvery proposal,
> and it brings fairly obvious improvements to the table (which table?).
> I still need some kind of BDFL or BDFL delegate to do that, though --
> unless I am allowed to mark my own PEP accepted :-)

Try it and see whether anyone complains ;-)

I like it.  I didn't review the code, but the PEP addresses real
issues, and the solutions look good on paper ;-)

One thing I wonder about:  I don't know that non-seekable pickle
streams are important use cases, but am willing to be told that they
are.  In which case, framing is a great idea.

But I wonder why it isn't done with a new framing opcode instead (say,
FRAME followed by 8-byte count).  I suppose that would be like the
"prefetch" idea, except that framing opcodes would be mandatory
(instead of optional) in proto 4.  Why I initially like that:

- Uniform decoding loop ("the next thing" _always_ starts with an opcode).

- Some easy sanity checking due to the tiny redundancy (if the byte
immediately following the current frame is not a FRAME opcode, the
pickle is corrupt; and also corrupt if a FRAME opcode is encountered
_inside_ the current frame).

When slinging 8-byte counts, _some_ sanity-checking seems like a good idea ;-)