[Python-Dev] test_gzip/test_tarfile failure om AMD64

[Guido van Rossum]

On 5/29/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Thomas Wouters]
> > ...
> > Perhaps more people could chime in? Am I being too anal about backward
> > compatibility here?
>
> Yes and no ;-)  Backward compatibility _is_ important, but there seems
> no way to know in this case whether struct's range-checking sloppiness
> was accidental or deliberate.

I'm pretty sure it was deliberate. I'm more than likely the original
author of this code (since the struct module was originally mine), and
I know I put in things like that in a few places to cope with hex/oct
constants pasted from C headers, and the general messiness that ensued
because of Python's lack of an unsigned int type.

This is probably a case that was missed by PEP 237.

I think we should do as Thomas proposes: plan to make it an error in
2.6 (or 2.7 if there's a big outcry, which I don't expect) and accept
it with a warning in 2.5.

> - If it _was_ intended that range-checking be sloppy, nobody
>   bothered to document it.

Mea culpa. In those days we didn't document a lot of things.

> - Or even to write a comment in the code explaining that obscure
>   intent.

It never occurred to me that it was obscure; we did this all over the
place (in PyArg_Parse too).

> - When I implemented the Q (8-byte int) format code, I added
>   correct range-checking in all cases, and nobody ever complained
>   about that.

It's really only a practical concern for 32-bit values on 32-bit
machines, where reasonable people can disagree over whether 0xffffffff
is -1 or 4294967295.

> - As noted in the comment above, we have gotten complaints about
>   failures of struct range-checking at other integer widths.
>
> OTOH,  BUGGY_RANGE_CHECK existed because I was too timid to risk
> making broken user code visibly broken.
>
> So, in all, I'm 95% sure 2.4's behavior is buggy, but 50% unsure that
> we need to warn about it before repairing it.  Since you (Thomas) want
> warnings, and in theory it only affects the lightly-used "standard"
> modes, I do lean in favor of leaving the standard modes that _are_
> broken (as above, not all are) broken in 2.5 but warning that this
> will change in 2.6.

I'm not sure what we gain by leaving other std modules depending on
struct's brokenness broken. But I may be misinterpreting which modules
you're referring to.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)