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

[Eric S. Raymond]

Guido van Rossum <guido@digicool.com>:
> > 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.

Likewise from me -- that is, +1 on Tim's proposed format and +0 on stuff like
hashes and embedded source pathnames and stuff.  

As Tim observed earlier, I just want to see some progress made; I'm
not picky about the low-level details on this one, though I'll be
happy with the invariant tag and the PNG-style sanity check.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Extremism in the defense of liberty is no vice; moderation in the
pursuit of justice is no virtue."
	-- Barry Goldwater (actually written by Karl Hess)