Guido van Rossum wrote:
I recently posted a patch to fix a bug: http://python.org/sf/561858. The patch requires changing .pyc magic. Since this bug goes back to 2.1, what is the process for changing .pyc magic in bugfix releases? ie, is it allowed?
Absolutely not!!!!! .pyc files must remain 100% compatible!!! (Imagine someone doing a .pyc-only distribution for 2.1.3 and finding that it doesn't work for 2.1.4!)
Ok, I'll work on a patch for 2.1/2.2.
In looking through other magic code, I found that when -U was removed. It was only removed from the usage msg. Should the option and code be removed altogether? ie, -U is still used by getopt and still changes the magic, so -U is just a hidden option now.
It also brings up a related problem. If the PyCodeObject can't be written to disk, should a .pyc be created at all? The code will run fine the first time, but when imported the second time it will fail.
What do you mean by "can't be written to disk"? Is the disk full? Is there another kind of write error? The magic number is written last, only when the write is successful.
Disk full was one condition. The other condition was the if a value is 32 bits in memory, but only 16 bits are written to disk. Based on your comment to increase all of the 16 bit values for PyCode, that will no longer be the case. Although, there could be transient write errors and the file could be corrupted. Since only part of the data would be written. One case where this could happen is an interupted system call.
There is one other possible problem. [wr]_short() is now only used in one place: for long.digits which are unsigned ints. But r_short() does sign extension. Is this a problem?