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 arrived at, although 2.4.3's checking behavior is
>> actually so inconsistent that "it" needs some defining (what exactly
>> are we trying to still accept? e.g., that -1 doesn't trigger "I"
>> complaints but that -1L does above? that one's surely a bug).
>
> No, it reflects that (up to 2.3 I believe) 0xffffffff was -1 but
> 0xffffffffL was 4294967295L.
Python 2.3 did a FutureWarning on 0xffffffff but its value was -1.
Anyway, my plan is to make it such that all non-native format codes
will behave exactly like C casting, but will do a DeprecationWarning
for input numbers that were initially out of bounds. This behavior
will be consistent across (python) int and long, and will be easy
enough to explain in the docs (but still more complicated than
"values not representable by this data type will raise struct.error").
This means that I'm also changing it so that struct.pack will not
raise OverflowError for some longs, it will always raise struct.error
or do a warning (as long as the input is int or long).
Pseudocode looks kinda like this:
def wrap_unsigned(x, CTYPE):
if not (0 <= x <= CTYPE_MAX):
DeprecationWarning()
x &= CTYPE_MAX
return x
Actually, should this be a FutureWarning or a DeprecationWarning?
-bob
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
