[Python-Dev] Identifying magic prefix on Python files?

[Tim Peters]

[Eric S. Raymond]
> Python's .pyc files don't have a magic prefix that the file(1)
> utility can recognize.

Well, they *do* (#define MAGIC in import.c), but it changes from time to
time.  Here's a NEWS item from 2.1a1:

    - The interpreter accepts now bytecode files on the command
      line even if they do not have a .pyc or .pyo extension. On
      Linux, after executing

      echo ':pyc:M::\x87\xc6\x0d\x0a::/usr/local/bin/python:' >
         /proc/sys/fs/binfmt_misc/register

      any byte code file can be used as an executable (i.e. as an
      argument to execve(2)).

However, the magic number has changed twice since then (in import.c rev
2.157 and again in rev 2.160), so the NEWS item is two changes obsolete.
The current magic number can be obtained (as a 4-bytes string) via

import imp
MAGIC = imp.get_magic()

> Would anyone object if I fixed this?

Undoubtedly, but not me <wink>.  Mucking with the .pyc prefix is always
contentious.

> A trivial pair of hacks to the compiler and interpreter would
> do it.

Also need to adjust .py files using imp.get_magic().

  Backward compatibility would be easily arranged.  Embedding
> the Python version number in the prefix might enable some useful
> behavior down the road.

Note that the current scheme uses a 4-byte value, where the last two bytes
are fixed, and the first two are

   (year-1995)*10000 + (month * 100) + day

where month and day are 1-based.  What it's recording (unsure this is
explained anywhere) is the day on which an incompatible change got made to
the PVM.  This is important to check so that whatever version of Python
you're running doesn't try to execute bytecodes generated for an
incompatible PVM.  But only Python has a chance of understanding this.

Note too that the method used for encoding the date runs out of bits at the
end of 2001, so the current scheme is on its last legs regardless.

couldn't-be-simpler<wink>-ly y'rs  - tim