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

[Tim Peters]

[Guido]
> Hm, that's not the reason the magic number ends in \r\n.
> ... [Mac silliness, for a change] ...
> Later compilers on the Mac weren't so stupid, and now the fact that
> this lets you discover text translation errors is just a pleasant
> side-effect.
>
> Personally, I don't care about this property any more.

Don't know about Macs (although I believe the Metrowerks libc can be still
be *configured* to swap \r and \n there), but it caught a bug in Python in
the 2.0 release cycle (where Python was opening .pyc files in text mode by
mistake, but only on Windows).  Well, actually, it didn't catch anything, it
caused import from .pyc to fail silently.  Having *some* specific gross
thing fail every time is worth something.

But the \r\n thingie can be pushed into the extended header instead.  Here's
an idea for "the new" magic number, assuming it must remain 4 bytes:

byte 0:  \217  will never change
byte 1:  'P'   will never change
byte 2:  high-order byte of version number
byte 3:  low-order byte of version number

"Version number" is an unsigned 16-bit int, starting at 0 and incremented by
1 from time to time.  64K changes may even be enough to get us to Python
3000 <wink>.  A separate text file should record the history of version
number changes, associating each with the date, release and reason for
change (the CVS log for import.c used to be good about recording the reason,
but not anymore).

Then we can keep a 4-byte magic number, Eric can have his invariant two-byte
tag at the start, and it's still possible to compare "version numbers"
easily for more than just equality (read the magic number as a "network
standard" unsigned int, and it's a total ordering with earlier versions
comparing less than later ones).  The other nifty PNG sanity-checking tricks
can also move into the extended header.

all-obvious-to-the-most-casual-observer-ly y'rs  - tim