<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 8 Sep 2017 at 10:53 Benjamin Peterson <<a href="mailto:benjamin@python.org">benjamin@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you all for the feedback. I've now updated the PEP to specify a<br>
4-word pyc header with a bit field in every case.<br>
<br>
On Fri, Sep 8, 2017, at 09:43, Nick Coghlan wrote:<br>
> On 8 September 2017 at 07:55, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
> > On Fri, 8 Sep 2017 07:49:46 -0700<br>
> > Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
> >> > I'd rather a single magic number and a separate bitfield that tells<br>
> >> > what the header encodes exactly.  We don't *have* to fight for a tiny<br>
> >> > size reduction of pyc files.<br>
> >><br>
> >> One of Benjamin's goals was for the existing timestamp-based pyc<br>
> >> format to remain completely unchanged, so we need some kind of marker<br>
> >> in the magic number to indicate whether the file is using the new<br>
> >> format or nor.<br>
> ><br>
> > I don't think that's a useful goal, as long as we bump the magic number.<br>
><br>
> Yeah, we (me, Benjamin, Greg) discussed that here, and we agree -<br>
> there isn't actually any benefit to keeping the timestamp based pyc's<br>
> using the same layout, since the magic number is already going to<br>
> change anyway.<br>
><br>
> Given that, I think your suggested 16 byte header layout would be a<br>
> good one: 4 byte magic number, 4 bytes reserved for format flags, 8<br>
> bytes with an interpretation that depends on the format flags.<br>
><br></blockquote><div><br></div><div>+1 from me! <br></div></div></div>