<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 19, 2013 at 2:09 PM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Well, I don't think it's a big deal to add a FRAME opcode if it doesn't<br>
change the current framing logic. I'd like to defer to Alexandre on this<br>
one, anyway.</blockquote><div><div><br></div><div>Looking at the different options available to us:</div><div><br></div><div>1A. Mandatory framing</div><div>      (+) Allows the internal buffering layer of the Unpickler to rely</div>

<div>          on the presence of framing to simplify its implementation.</div><div>      (-) Forces all implementations of pickle to include support for</div><div>          framing if they want to use the new protocol.</div>

<div>      (-) Cannot be removed from future versions of the Unpickler</div><div>          without breaking protocols which mandates framing.</div><div>1B. Optional framing</div><div>      (+) Could allow optimizations to disable framing if beneficial</div>

<div>          (e.g., when pickling to and unpickling from a string).</div><div><br></div><div>2A. With explicit FRAME opcode</div><div>      (+) Makes optional framing simpler to implement.</div><div>      (+) Makes variable-length encoding of the frame size simpler</div>

<div>          to implement.</div><div>      (+) Makes framing visible to pickletools.</div><div>      (-) Adds an extra byte of overhead to each frames.</div><div>2B. No opcode</div><div><br></div><div>3A. With fixed 8-bytes headers</div>

<div>     (+) Is simple to implement</div><div>     (-) Adds overhead to small pickles.</div><div>3B. With variable-length headers</div><div>     (-) Requires Pickler implemention to do extra data copies when</div><div>         pickling to strings.</div>

<div><br></div><div>4A. Framing baked-in the pickle protocol</div><div>     (+) Enables faster implementations</div><div>4B. Framing through a specialized I/O buffering layer</div><div>     (+) Could be reused by other modules</div>

<div><br></div><div>I may change my mind as I work on the implementation, but at least for now, I think the combination of 1B, 2A, 3A, 4A will be a reasonable compromise here.</div></div><div><br></div></div></div></div>