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.py:63:
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 pack as p
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-exceptional
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 comments in
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 because I had no
[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
a
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 masking)
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
On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote:
Well, the behavior change is in response to a bug http://python.org/sf/1229380.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 how
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 http://python.org/sf/1229380. If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is the
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 fix
[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
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 want, yes:
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
[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, but
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
actually so
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
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.
That's what I
[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 needs some
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, it's
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, should
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 define
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't expect) and
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
up to
[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 in
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
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
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:
28 matches
Mail list logo
