<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 8:10 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 18 Nov 2013 07:48:27 -0800<br>
Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>>wrote:<br>
><br>
> > 18.11.13 07:53, Tim Peters написав(ла):<br>
> ><br>
> >  - Some easy sanity checking due to the tiny redundancy (if the byte<br>
> >> immediately following the current frame is not a FRAME opcode, the<br>
> >> pickle is corrupt; and also corrupt if a FRAME opcode is encountered<br>
> >> _inside_ the current frame).<br>
> >><br>
> ><br>
> > For efficient unpickling a FRAME opcode followed by 8-byte count should be<br>
> > *last* thing in a frame (unless it is a last frame).<br>
> ><br>
><br>
> I don't understand that.<br>
><br>
> Clearly the framing is the weakest point of the PEP (== elicits the most<br>
> bikeshedding). I am also unsure about the value of framing when pickles are<br>
> written to strings.<br>
<br>
</div></div>It hasn't much value in that case, but the cost is also small (8 bytes<br>
every 64KB, roughly).<br clear="all"></blockquote><div><br></div><div>That's small if your pickle is large, but for small pickles it can add up. Still, not enough to reject the PEP. Just get Tim to agree with you, or switch to Tim's proposal. <br>

</div></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>