[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 ;-)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4