[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: The backport looks fine. Applied in r80917. Thanks, Alexander. -- resolution: accepted -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Yes, okay---that makes some sense; I'm happy to leave floats as they are (i.e., DeprecationWarning for small floats; TypeError for larger floats) and just fix use of __int__ for non-floats. I'll look at the patch. -- assignee: belopolsky -> mark.dic

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17231/issue1533-release26-maint.diff ___ Python tracker ___ ___ Pyth

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: > the requirements are different for 2.6: floats should give a > DeprecationWarning rather than a TypeError. I thought about it, but the comment in test_builtin.py, # Reject floats when it would require PyLongs to represent.

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: > I've never done a maintenance branch backport, but here is my attempt: [...] Yes, that sounds about right. But after all that, you'll still need to modify the patch somewhat, since the requirements are different for 2.6: floats should give a DeprecationWa

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : -- keywords: +26backport versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker ___ __

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: > Alexander, do you want to tackle the 2.6 backport? I've never done a maintenance branch backport, but here is my attempt: 1. Checkout release26-maint 2. Apply 80757:80758 diff, fix rejected NEWS patch 3. Ignore 80838:80839 diff - small floats are accep

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: That should have been r80839, not r80842. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue1533] Bug in range() function for large values

Changes by Mark Dickinson : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/op

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Bah. That's r80841, not r80842. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Perfect! Committed in r80836 (py3k); fixed that one test and comment in r80842 in trunk. Alexander, do you want to tackle the 2.6 backport? BTW, I think in most cases it's unnecessary to add Python 3.3 to the Versions field above, since there's no correspo

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: I am attaching a py3k patch that adds new tests. Since there are no end user visible changes, I don't believe a Misc/NEWS entry is needed. A commit message may read: Issue #1533: Tests only. Added tests for consistency in range function argument proc

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: +1 for forward-porting/adapting relevant tests to py3k. -- assignee: mark.dickinson -> belopolsky ___ Python tracker ___ ___

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On Tue, May 4, 2010 at 12:32 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Applied to trunk in r80758. > > Do people want this to go into 2.6 as well? Also, should additional unit tests forward ported to 3.x? If so, let me do it a

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Applied to trunk in r80758. Do people want this to go into 2.6 as well? The patch would need to be modified to produce a warning for floats instead of giving a TypeError (and the tests would need to be modified to test for that warning). -- ___

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: [Some of the Alexander's questions about procedures aren't really related to this issue; I've answered those offline. Here are the answers to the others.] >> - initialize low to NULL, to match the Py_XDECREF(low) (could change >> that Py_XDECREF to Py_DE

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : -- assignee: belopolsky -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On Tue, May 4, 2010 at 8:34 AM, Mark Dickinson wrote: .. > I took the liberty of messing with your patch slightly; I didn't want > to ask you to make further changes since the patch was fine, and my > messing was mostly just to satisfy my own fussiness (

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Re emacs: C-c . python should set a python 2.x-friendly indentation mode. There's also a python-new style floating around somewhere on the web (not part of emacs as standard), suitable for the 4-space indent style that's supposed to be used for new code. -

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: I see. Let me take a look. BTW, I tried to use tabs for indentation in the patch, but emacs was not always happy about it. Is there some c-mode setting that I don't know about that would take care of that? On May 4, 2010, at 8:34 AM, Mark Dickinson

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Hi Alexander, I took the liberty of messing with your patch slightly; I didn't want to ask you to make further changes since the patch was fine, and my messing was mostly just to satisfy my own fussiness (only the first two items were really necessary): Mi

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On May 4, 2010, at 7:27 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Thanks for the fixes. The latest patch looks good to me. > > Alexander, is it okay for me to commit this? > Sure. Why do you have to ask? -- nosy: +

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Thanks for the fixes. The latest patch looks good to me. Alexander, is it okay for me to commit this? -- resolution: -> accepted ___ Python tracker _

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17189/issue1533.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: > - Please could you also add a test for small arguments for each test > class? Done. -- Added file: http://bugs.python.org/file17190/issue1533.diff ___ Python tracker __

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On Sun, May 2, 2010 at 4:37 AM, Mark Dickinson wrote: .. >  - Please could you also add a test for small arguments for each test >   class? Working on it ... -- ___ Python tracker

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17171/bltinmodule3.diff ___ Python tracker ___ ___ Python-bugs-list

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17176/bltinmodule4.diff ___ Python tracker ___ ___ Python-bugs-list

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file9543/bltinmodule.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Attached patch, issue1533.diff, simplifies reference acrobatics at the expense of extra local variables. For the first time the first compilation did not have reference counting errors! -- Added file: http://bugs.python.org/file17189/issue1533.

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: BTW, I've changed the various "nb_int should return int object" error messages in Objects/intobject.c to the more meaningful and accurate message: "__int__ method should return an integer", in r80695. -- ___ Python

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Thinking about it a bit more, I really would prefer get_range_argument not to steal a reference. If I'm reading a bit of C code and encounter something like: obj = transform(obj); if (obj == NULL) ... my hindbrain immediately starts fretting that somethi

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Thanks---the new patch looks good. Pulling the argument conversion out into a separate function makes the whole thing much cleaner. I still have a couple of nits: - Please add a comment before get_range_argument indicating what it's for. I'd also consid

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17175/bltinmodule4.diff ___ Python tracker ___ ___ Python-bugs-list

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file17176/bltinmodule4.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: This patch, bltinmodule4.diff, seems to work for all cases. Mark, It looks like I came up with almost the same logic as you did. The only difference that I can see is that your code does not check that nb_int returns an integer. Also I put repeated

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Alexander, I think it should be as simple as replacing the if (!PyInt_Check(ilow) && ...) block with something like this: if (!PyInt_Check(ilow) && !PyLong_Check(ilow)) { PyNumberMethods *nb = Py_TYPE(ilow)->tp_as_number;

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Mark, I did not see your last comment before uploading the last patch. I think your suggestion to bypass PyNumber_Long will fix the new/old style classes discrepancy. -- ___ Python tracker

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: I am attaching a patch which does not crash or leak (as tested with -R :) and adds a unit test for OP's case. The problem, however is that it does not work if new style classes are used in the test case. See disabled (with if 0) test in the patch. I'l

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: A couple of suggestions regarding the patch: (1) I'd suggest leaving the first part of handle_range_longs intact, up to and including the "/* ilow and ihigh correct now; do istep */" block. Then build out the three "if (!PyInt_Check(...)) ..." blocks below t

[issue1533] Bug in range() function for large values

Changes by Mark Dickinson : -- resolution: out of date -> status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: > Hmm, maybe there is a 2.7 bug here after all: Yes, indeed! Which is why I was suggesting 'wont fix' rather than 'out of date' :) The bltinmodule2.diff patch from Robert causes a segfault in test_builtin on my system; I haven't looked at the patch itself

[issue1533] Bug in range() function for large values

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker ___ ___ Python

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Robert, Your patch segfaults on Lib/test/test_builtin.py, but I agree with the approach. I'll see if it is easy to fix. -- ___ Python tracker __

[issue1533] Bug in range() function for large values

Robert Bradshaw added the comment: Thank you Alexander. Yes, there is still an issue for large operands, and the attached patch does fix it. Floats are explicitly checked for and rejected by PyArg_ParseTuple for the "l" format (as called by builtin_range) so to preserve this behavior we can e

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On Sat, May 1, 2010 at 10:59 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Decimal is behaving in exactly the same way as MyInt, isn't it? > What do you get for range(MyInt(20), MyInt(20))? > Hmm, maybe there is a 2.7 bug here afte

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Decimal is behaving in exactly the same way as MyInt, isn't it? What do you get for range(MyInt(20), MyInt(20))? -- ___ Python tracker ___

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: On Sat, May 1, 2010 at 3:50 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Alexander: range *does* still accept such arguments (in 2.7);  just not > floats: > from decimal import Decimal range(Decimal(20), Decimal(20)) > [

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Alexander: range *does* still accept such arguments (in 2.7); just not floats: >>> from decimal import Decimal >>> range(Decimal(20), Decimal(20)) [] >>> range(Decimal('1e100'), Decimal('1e100')) Traceback (most recent call last): File "", line 1, in TypeEr

[issue1533] Bug in range() function for large values

Changes by Martin v. Löwis : -- resolution: wont fix -> out of date status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: I agree that this issue should be closed with no further action, but for historical accuracy the resolution should be "out of date" rather than "won't fix". The original bug was about range() behavior when it get arguments that are not ints, but "coerc

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: > IIRC, it was a very deliberate choice not to allow float arguments to range Ignore this bit. IDRC. It was a deliberate choice not to let something range(0.0, 1.0, 0.1) work to give [0.0, 0.1, ...], since the usual floating-point difficulties give uncertai

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: Currently, in trunk, I get: >>> range(0.0, 11.0, 1.1) Traceback (most recent call last): File "", line 1, in TypeError: range() integer start argument expected, got float. But with Alexander's patch on trunk, I get: >>> range(0.0, 11.0, 1.1) [0L, 1L, 2L, 3

[issue1533] Bug in range() function for large values

Mark Dickinson added the comment: As far as I can tell there's no bug in 3.x: the 3.x range happily accepts an instance of a class that defines __index__. -- versions: -Python 3.1, Python 3.2 ___ Python tracker

[issue1533] Bug in range() function for large values

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1533] Bug in range() function for large values

Changes by Brian Curtin : -- priority: -> normal type: crash -> behavior versions: +Python 3.1, Python 3.2 -Python 3.0 ___ Python tracker ___

[issue1533] Bug in range() function for large values

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue1533] Bug in range() function for large values

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This change is out of scope for 2.5.3 (plus, the desired behavior still seems to be debated) -- nosy: +loewis versions: -Python 2.5, Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]>

[issue1533] Bug in range() function for large values

Akira Kitada <[EMAIL PROTECTED]> added the comment: Updating versions. -- versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue1533] Bug in range() function for large values

Robert Bradshaw <[EMAIL PROTECTED]> added the comment: I think *both* behaviors are wrong, the 3.0 one is backwards incompatible, and the 2.7 one is inconsistent (accepting MyInt if it's < 32 bits, rejecting it for > 64 bits). For our particular use case, it is very annoying to not be able to u

[issue1533] Bug in range() function for large values

Akira Kitada <[EMAIL PROTECTED]> added the comment: I'm just curious to know which is the right behavior. # Python 3.0 Traceback (most recent call last): File "bad_range.py", line 7, in print(range(MyInt(2**3), MyInt(2**3+10))) TypeError: 'MyInt' object cannot be interpreted as an integer

[issue1533] Bug in range() function for large values

Robert Bradshaw added the comment: Alexander Belopolsky's patch looks like the right fix for range() to me. The xrange limits still hold, but that should probably be a separate issue/ticket. __ Tracker <[EMAIL PROTECTED]> _

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Attached patch addresses OP's issue: $ ./python.exe bad_range.py [8, 9, 10, 11, 12, 13, 14, 15, 16, 17] here [18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 184467

[issue1533] Bug in range() function for large values

Christian Heimes added the comment: I'm working on the memory problem. See #2039 and #2013. xrange is a totally different story. I'm +0 on changing xrange. Is Python 3.0's range function compatible with xrange? If the answer is yes, we may reuse the code for an unlimited xrange. ___

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: > So far the memory for the ints is *never* returned > to the system. I'm working on the problem. Christian, Are you working on the memory problem or on this issue? I think I have a solution to OP's problem, but don't want to duplicate your effort.

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Christian, I was probably a bit sloppy using "range" instead of "xrange," but issue1540617 is limited to xrange only. Are you still -10 on extending xrange on 64-bit platforms to +/- 2**63? If so, what is your position on backporting py3k's unlimited

[issue1533] Bug in range() function for large values

Christian Heimes added the comment: I'm -10 on the patch in issue1540617 ( +/-2**63). Reason: It's a good thing that the range of "range" is limited since it returns a list of integers. range(2**32) allocates (2**32)*16 bytes + small overhead for ints plus the space for the list (probably (2**32

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: This is related to issue1540617 and issue1546078. issue1540617 contains a simple patch that extend acceptable range of argument to +/-2**63 issue1546078 contains a complete long integer support implementation and was accepted in Py3k. It looks like al

[issue1533] Bug in range() function for large values

Rafael Zanella added the comment: According to the documentation (http://docs.python.org/dev/library/functions.html) "The arguments must be plain integers", so I think the wrong thing here is to run the object's __int__() under the range()'s hood. I think the right thing to do would be to explici

[issue1533] Bug in range() function for large values

Robert Bradshaw added the comment: Yes, the error for xrange is more illustrative of the problem, but just shows that xrange has this a too. Why should xrange be invalid for non-word sized values (especially as range works)? Incidentally, just a week ago I had to write my own iterator for a proje

[issue1533] Bug in range() function for large values

Rafael Zanella added the comment: FWIW, using xrange() it seems to give the proper error message: Traceback (most recent call last): File "bad_range.py", line 12, in print xrange(MyInt(2**64), MyInt(2**64+10)) OverflowError: long int too large to convert to int -- nosy: +zanella

[issue1533] Bug in range() function for large values

Changes by Raymond Hettinger: -- assignee: -> rhettinger nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1533] Bug in range() function for large values

Robert Bradshaw added the comment: Yes, that is a workaround, but range(MyInt(n), MyInt(n+10)) should work for any valid value of n, not just some of them. __ Tracker <[EMAIL PROTECTED]> __

[issue1533] Bug in range() function for large values

jos added the comment: Is this a bug? print range(MyInt(2**64), MyInt(2**64+10)) produced TypeError: range() integer start argument expected, got instance. print range(int(MyInt(2**64)), int(MyInt(2**64+10))) should work. -- nosy: +josm __ Tracker <[

[issue1533] Bug in range() function for large values

New submission from Robert Bradshaw: Range accepts arguments coerce-able into ints via __int__, but rejects arguments coerce-able into longs but to large to fit into an int. The problem is in handle_range_longs in bltinmodule.c:1527-1541. If they type is not an int or long, it should try to mak