On Tue, May 30, 2000 at 09:08:15AM +0200, Peter Funk wrote:
I would recommend the approach of adding opcodes into the marshal format. Specifically, 'V' followed by a single byte. That can only occur at the beginning. If it is not present, then you know that you have an old marshal value.
But this would not solve the problem with 8 byte versus 4 byte timestamps in the header on 64-bit OSes. Trent Mick pointed this out.
I kind of intimated but did not make it clear: I wouldn't worry about the limitations of a 4 byte timestamp too much. That value is not going to overflow for another 38 years. Presumably the .pyc header (if such a thing even still exists then) will change by then. [peter summarizes .pyc header format options]
If we decide to move the version number into the marshal, if we can also move the .py-timestamp there. This way the timestamp will be handled in the same way as large integer literals. Quoting from the docs:
"""Caveat: On machines where C's long int type has more than 32 bits (such as the DEC Alpha), it is possible to create plain Python integers that are longer than 32 bits. Since the current marshal module uses 32 bits to transfer plain Python integers, such values are silently truncated. This particularly affects the use of very long integer literals in Python modules -- these will be accepted by the parser on such machines, but will be silently be truncated when the module is read from the .pyc instead. [...] A solution would be to refuse such literals in the parser, since they are inherently non-portable. Another solution would be to let the marshal module raise an exception when an integer value would be truncated. At least one of these solutions will be implemented in a future version."""
Should this be 1.6? Changing the format of .pyc files over and over again in the 1.x series doesn't look very attractive.
I *hope* it gets into 1.6, because I have implemented the latter suggestion (raise an exception is truncation of a PyInt to 32-bits will cause data loss) in the docs that you quoted and will be submitting a patch for it on Wed or Thurs. Ciao, Trent -- Trent Mick trentm@activestate.com