(original) (raw)

Thank you all for the feedback. I've now updated the PEP to specify a
4-word pyc header with a bit field in every case.

On Fri, Sep 8, 2017, at 09:43, Nick Coghlan wrote:
\> On 8 September 2017 at 07:55, Antoine Pitrou <solipsis@pitrou.net> wrote:
\> > On Fri, 8 Sep 2017 07:49:46 -0700
\> > Nick Coghlan <ncoghlan@gmail.com> wrote:
\> >> > I'd rather a single magic number and a separate bitfield that tells
\> >> > what the header encodes exactly. We don't \*have\* to fight for a tiny
\> >> > size reduction of pyc files.
\> >>
\> >> One of Benjamin's goals was for the existing timestamp-based pyc
\> >> format to remain completely unchanged, so we need some kind of marker
\> >> in the magic number to indicate whether the file is using the new
\> >> format or nor.
\> >
\> > I don't think that's a useful goal, as long as we bump the magic number.
\>
\> Yeah, we (me, Benjamin, Greg) discussed that here, and we agree -
\> there isn't actually any benefit to keeping the timestamp based pyc's
\> using the same layout, since the magic number is already going to
\> change anyway.
\>
\> Given that, I think your suggested 16 byte header layout would be a
\> good one: 4 byte magic number, 4 bytes reserved for format flags, 8
\> bytes with an interpretation that depends on the format flags.
\>