[Python-Dev] Accepting PEP 3154 for 3.4?

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