Summary of .pyc-Discussion so far (was Re: [Python-Dev] Proposal: .pyc file format change)
Tue, 30 May 2000 00:46:09 -0700
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.