[Python-Dev] Accepting PEP 3154 for 3.4? (original) (raw)

Tim Peters tim.peters at gmail.com
Mon Nov 18 23:02:31 CET 2013

[Guido]

Clearly the framing is the weakest point of the PEP (== elicits the most bikeshedding). I am also unsure about the value of framing when pickles are written to strings.

[Antoine]

It hasn't much value in that case,

It has no value in that case, yes? It doesn't appear to have much value in the case of a seekable stream, either - the implementation has always been free to read ahead then. The real value appears to be in cases of non-seekable streams.

but the cost is also small (8 bytes every 64KB, roughly).

That's small if your pickle is large, but for small pickles it can add up.

Which is annoying. It was already annoying when the PROTO opcode was introduced, and the size of small pickles increased by 2 bytes. That added up too :-(

Still, not enough to reject the PEP. Just get Tim to agree with you, or switch to Tim's proposal.

I just asked a question ;-) If a mandatory proto 4 FRAME opcode were added, it would just increase the bloat for small pickles (up from the currently proposed 8 bytes of additional overhead to 9).

More information about the Python-Dev mailing list