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

[Guido van Rossum]

> 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.

Sounds to me that we'd caught this sooner without the \r\n gimmic. :-)

> 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.

+1 from me.  I'm +0 on adding more magic to the marshalled code.

--Guido van Rossum (home page: http://www.python.org/~guido/)