Bump the magic number to avoid sharing bytecode between 2.3 and 2.4.

Revise the long comment that explained details of the magic number
in gory detail.

1 files changed, 14 insertions, 32 deletions

diff --git a/Python/import.c b/Python/import.c
index 71ee6c3..5143a60 100644
--- a/Python/import.c
+++ b/Python/import.c
@@ -19,39 +19,20 @@
 extern time_t PyOS_GetLastModificationTime(char *, FILE *);
 						/* In getmtime.c */
 
-/* Magic word to reject .pyc files generated by other Python versions */
-/* Change for each incompatible change */
-/* The value of CR and LF is incorporated so if you ever read or write
+/* Magic word to reject .pyc files generated by other Python versions.
+   It should change for each incompatible change to the bytecode.
+
+   The value of CR and LF is incorporated so if you ever read or write
    a .pyc file in text mode the magic number will be wrong; also, the
    Apple MPW compiler swaps their values, botching string constants.
-   XXX That probably isn't important anymore.
-*/
-/* XXX Perhaps the magic number should be frozen and a version field
-   added to the .pyc file header? */
-/* New way to come up with the low 16 bits of the magic number:
-      (YEAR-1995) * 10000 +  MONTH * 100 + DAY
-   where MONTH and DAY are 1-based.
-   XXX Whatever the "old way" may have been isn't documented.
-   XXX This scheme breaks in 2002, as (2002-1995)*10000 = 70000 doesn't
-       fit in 16 bits.
-   XXX Later, sometimes 1 gets added to MAGIC in order to record that
-       the Unicode -U option is in use.  IMO (Tim's), that's a Bad Idea
-       (quite apart from that the -U option doesn't work so isn't used
-       anyway).
-
-   XXX MAL, 2002-02-07: I had to modify the MAGIC due to a fix of the
-       UTF-8 encoder (it previously produced invalid UTF-8 for unpaired
-       high surrogates), so I simply bumped the month value to 20 (invalid
-       month) and set the day to 1.  This should be recognizable by any
-       algorithm relying on the above scheme. Perhaps we should simply
-       start counting in increments of 10 from now on ?!
-
-       MWH, 2002-08-03: Removed SET_LINENO.  Couldn't be bothered figuring
-       out the MAGIC schemes, so just incremented it by 10.
-
-       GvR, 2002-08-31: Because MWH changed the bytecode again, moved the
-       magic number *back* to 62011.  This should get the snake-farm to
-       throw away its old .pyc files, amongst others.
+
+   Apparently, there was a distinction made between even and odd
+   bytecodes that is related to Unicode.  The details aren't clear,
+   but the magic number has been odd for a long time.
+
+   There were a variety of old schemes for setting the magic number.
+   The current working scheme is to increment the previous value by
+   10.
 
    Known values:
        Python 1.5:   20121
@@ -66,8 +47,9 @@ extern time_t PyOS_GetLastModificationTime(char *, FILE *);
        Python 2.3a0: 62011
        Python 2.3a0: 62021
        Python 2.3a0: 62011 (!)
+       Python 2.4a0: 62031
 */
-#define MAGIC (62011 | ((long)'\r'<<16) | ((long)'\n'<<24))
+#define MAGIC (62031 | ((long)'\r'<<16) | ((long)'\n'<<24))
 
 /* Magic word as global; note that _PyImport_Init() can change the
    value of this global to accommodate for alterations of how the