[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 ;-) _______________________________________________ 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