Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 31, 2006, at 8:31 AM, Tim Peters wrote: > I'm afraid a sabbatical year isn't long enough to understand what the > struct module did or intends to do by way of range checking <0.7 > wink>. > > Is this intended? This is on a 32-bit Windows box with current trunk: > from struct import p

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

I'm afraid a sabbatical year isn't long enough to understand what the struct module did or intends to do by way of range checking <0.7 wink>. Is this intended? This is on a 32-bit Windows box with current trunk: >>> from struct import pack as p >>> p("I", 2**32 + 2343) C:\Code\python\lib\struct.

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 30, 2006, at 10:47 AM, Tim Peters wrote: > [Bob Ippolito] >> What should it be called instead of wrapping? > > I don't know -- I don't know what it's trying to _say_ that isn't > already said by saying that the input is out of bounds for the format > code. The wrapping (now overflow maski

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[Bob Ippolito] > What should it be called instead of wrapping? I don't know -- I don't know what it's trying to _say_ that isn't already said by saying that the input is out of bounds for the format code. > When it says it's wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 > to force >

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 30, 2006, at 2:41 AM, Nick Coghlan wrote: > Bob Ippolito wrote: >> On May 29, 2006, at 8:00 PM, Tim Peters wrote: >>> We certainly don't want to see two deprecation warnings for a single >>> deprecated behavior. I suggest eliminating the "struct integer >>> wrapping" warning, mostly becaus

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

Bob Ippolito wrote: > On May 29, 2006, at 8:00 PM, Tim Peters wrote: >> We certainly don't want to see two deprecation warnings for a single >> deprecated behavior. I suggest eliminating the "struct integer >> wrapping" warning, mostly because I had no idea what it _meant_ >> before reading the co

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 8:00 PM, Tim Peters wrote: > [Bob Ippolito] >>> ... >>> Actually, should this be a FutureWarning or a DeprecationWarning? > > Since it was never documented, UndocumentedBugGoingAwayError ;-) > Short of that, yes, DeprecationWarning. FutureWarning is for changes > in non-excep

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[Bob Ippolito] >> ... >> Actually, should this be a FutureWarning or a DeprecationWarning? Since it was never documented, UndocumentedBugGoingAwayError ;-) Short of that, yes, DeprecationWarning. FutureWarning is for changes in non-exceptional behavior (.e.g, if we swapped the meanings of "<" and

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 4:35 PM, Delaney, Timothy (Tim) wrote: > Thomas Wouters wrote: > >> If 2.5 warns and does the old thing, the upgrade path is easy and >> defendable. This is also why there are future statements -- I >> distinctly recall making the same argument back then :-) The cost of >> con

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

Thomas Wouters wrote: > If 2.5 warns and does the old thing, the upgrade path is easy and > defendable. This is also why there are future statements -- I > distinctly recall making the same argument back then :-) The cost of > continuing the misfeatures in struct for one release does not weigh > u

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 1:18 PM, Bob Ippolito wrote: > > On May 29, 2006, at 12:44 PM, Guido van Rossum wrote: > >> On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: 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'

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:> I know which 'it' I meant: the same 'it' as struct already accepts in> Python 2.4 and before. Yes, it's inconsistent between formatcodes and> valuetypes -- fixing that the whole point of the change -- but that's > how you d

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

Thomas Wouters wrote: > I know which 'it' I meant: the same 'it' as struct already accepts in > Python 2.4 and before. Yes, it's inconsistent between formatcodes and > valuetypes -- fixing that the whole point of the change -- but that's > how you define 'compatibility'; struct, by default, sho

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: [Tim]>> To be clear, Thomas proposed "accepting it" (whatever that means) until 3.0.[Guido]> Fine with me.So who has a definition for what "it" means? I know which 'it' I meant: the same 'it' as struct already accepts in Python 2.4 and before. Yes,

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[Guido] >>> 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. [Tim] >> That's what I arrived at, although 2.4.3's checking behavior is >> actually so inconsistent that "it" ne

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 12:44 PM, Guido van Rossum wrote: > On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: >>> 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. >> >> Th

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

>Perhaps more people could chime in? Am I being too anal about backward > >compatibility here? As a sometimes bug report reviewer, I would like the reported discrepancy between the public docs and visible code behavior fixed one way or the other (by changing the docs or code) since that is my w

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > 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. > > That's what I arrived at, although 2.4.3's checking behavior is > ac

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[Guido] > ... > It's really only a practical concern for 32-bit values on 32-bit > machines, where reasonable people can disagree over whether 0x > is -1 or 4294967295. Then maybe we should only let that one slide <0.5 wink>. ... [Tim] >> So, in all, I'm 95% sure 2.4's behavior is buggy,

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Tim Peters <[EMAIL PROTECTED]> 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 r

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

"Thomas Wouters" <[EMAIL PROTECTED]> wrote: > On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > > > > A compromise is to do proper range checking as a warning, and do the > > modulo math anyway... but is that what we really want? > > > > I don't know about the rest of 'us', but that's what I

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[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. Having

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: A compromise is to do proper range checking as a warning, and do the modulo math anyway... but is that what we really want?I don't know about the rest of 'us', but that's what I want, yes: backward compatibility, and a warning to tell people to fi

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 3:14 AM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Well, the behavior change is in response to a bug . If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is th

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Well, the behavior change is in response to a bug . If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is the only way to find them :) Feel free to comment ho

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 28, 2006, at 5:34 PM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:>> I'm seeing a dubious failure of test_gzip and test_tarfile on my> AMD64 machine. It's triggered by the recent struct changes, but I'd> say it's

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:>> I'm seeing a dubious failure of test_gzip and test_tarfile on my> AMD64 machine. It's triggered by the recent struct changes, but I'd> say it's probably caused by a bug/misfeature in zlibmodule:

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 28, 2006, at 4:31 AM, Thomas Wouters wrote: > > I'm seeing a dubious failure of test_gzip and test_tarfile on my > AMD64 machine. It's triggered by the recent struct changes, but I'd > say it's probably caused by a bug/misfeature in zlibmodule: > zlib.crc32 is the result of a zlib 'c

[Python-Dev] test_gzip/test_tarfile failure om AMD64

I'm seeing a dubious failure of test_gzip and test_tarfile on my AMD64 machine. It's triggered by the recent struct changes, but I'd say it's probably caused by a bug/misfeature in zlibmodule: zlib.crc32 is the result of a zlib 'crc32' functioncall, which returns an unsigned long. zlib.crc32 turns