[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Fair enough. Closing as won't fix. -- resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I still don't think the improvement in observable behavior is worth the cost of additional code (and as Alexander observes, the patch in file10234 is incorrect in boundary cases). __ Tracker <[EMAIL PROTECTED]

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: It's the current behaviour that seems arbitrary to me: a >> b is well- defined, and efficiently computable, for any integer a and nonnegative integer b; it seems odd to have an unnecessary and (from a user's viewpoint) arbitrary limit on th

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, May 9, 2008 at 7:08 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: .. > I'm -1 on this patch (or any other fixing the perceived problem). > Special cases aren't special enough to break the rules. > > If you ever see this error in

[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'm not sure I understand. What rule would be broken by this patch? The (implicit) rule that there is a range limitation on the shift width. The limitation would continue to exist, just not for selected left-hand parameters. This is fairl

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I'm not sure I understand. What rule would be broken by this patch? __ Tracker <[EMAIL PROTECTED]> __

[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I'm -1 on this patch (or any other fixing the perceived problem). Special cases aren't special enough to break the rules. If you ever see this error in a real application, you have deeper problems than the exception. -- nosy: +loewi

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > On the second thought, it is theoretically possible to have a long int a > for which a >> maxsize is not zero This occurred to me too; somehow this hardly seems worth worrying about- --there are already other problems in longobject.c when

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On the second thought, it is theoretically possible to have a long int a for which a >> maxsize is not zero because that would require only maxsize/15 digits. I am not sure it is worth the trouble to account for that. _

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Attached patch makes a >> b return 0 for b > maxsize. -- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file10234/issue2804.diff __ Tracker <[EMAIL PROTECTED]>

[issue2804] Integer right shift raises OverflowError when second operand is large

New submission from Mark Dickinson <[EMAIL PROTECTED]>: In Python 2.6a3: >>> 1 >> (2**31) # unexpected exception Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> 1 >> (2**31-1) # works as expected 0L It might make more sense for