Summary of .pyc-Discussion so far (was Re: [Python-Dev] Proposal: .pyc file format change)

[Trent Mick]

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