[issue2690] Precompute range length and enhance range subscript support

Daniel Stutzbach added the comment: Doc change committed to py3k in r87346. Thanks, SilentGhost! I also committed r87349 to reverse r87162 (which was in the wrong branch). -- ___ Python tracker __

[issue2690] Precompute range length and enhance range subscript support

SilentGhost added the comment: here is the patch for the py3k docs. -- Added file: http://bugs.python.org/file20021/stdtypes.rst.diff ___ Python tracker ___ _

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: No, I believe it was added as part of the .index() and .count() implementation. Checking the source, there's definitely no sq_contains implementation in 3.1 or 2.7. -- ___ Python tracker

[issue2690] Precompute range length and enhance range subscript support

Raymond Hettinger added the comment: Is the in/not-in fast path in 2.7? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: The other major change for ranges is that "in" and "not in" are no longer inefficient for actual instances of int (it does an arithmetic calculation instead of a linear search). -- ___ Python tracker

[issue2690] Precompute range length and enhance range subscript support

Raymond Hettinger added the comment: Applied in r87162 -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue2690] Precompute range length and enhance range subscript support

SilentGhost added the comment: Not sure this worth a patch, to me it looks like a removal of a single word. But here it goes anyway. -- nosy: +SilentGhost Added file: http://bugs.python.org/file20003/stdtypes.rst.diff ___ Python tracker

[issue2690] Precompute range length and enhance range subscript support

Daniel Stutzbach added the comment: The descriptions of range's limitations in the docs still needs an update. -- assignee: georg.brandl -> ncoghlan status: closed -> open ___ Python tracker ___

[issue2690] Precompute range length and enhance range subscript support

Georg Brandl added the comment: I'm fine with it: as with the other changes for .count and .index, consistency with the protocols/ABCs the types are members of is not exclusively a new feature. -- status: open -> closed ___ Python tracker

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: (Oops, didn't mean to reclose this yet) I want to wait for Georg's verdict on including the functionality in 3.2 before stressing too much about correct documentation of it :) -- assignee: -> georg.brandl status: closed -> open ___

[issue2690] Precompute range length and enhance range subscript support

Daniel Stutzbach added the comment: > The descriptions of range's limitations there is no longer accurate > (slicing is supported following this patch and containment testing is > now efficient) Want to open a new issue for that? (or is there one already?) --

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: Daniel Stutzbach pointed out that range() is also mentioned under: http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range The descriptions of range's limitations there is no longer accurate (slicing is supported foll

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: On Sat, Dec 4, 2010 at 2:26 AM, Daniel Stutzbach wrote: > > Daniel Stutzbach added the comment: > >> (I also noticed that the new methods from issue #9213 are not mentioned >> in the range() docs > > Wasn't that fixed in Issue9746? Ah, I see what you mean. I wa

[issue2690] Precompute range length and enhance range subscript support

Daniel Stutzbach added the comment: > (I also noticed that the new methods from issue #9213 are not mentioned > in the range() docs Wasn't that fixed in Issue9746? -- ___ Python tracker ___

[issue2690] Precompute range length and enhance range subscript support

Nick Coghlan added the comment: I brought the patch up to date for the Py3k branch, but realised just before checking it in that it may run afoul of the language moratorium (since it alters the behaviour of builtin range objects). However, the .count() and .index() methods (along with the Seq

[issue2690] Precompute range length

Nick Coghlan added the comment: I'd still like to have another look at this before beta 1, but can't promise I'll get to it. Unassigning in case someone else has some roundtuits to spare over the next few weeks. -- assignee: ncoghlan -> ___ Python

[issue2690] Precompute range length

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue2690] Precompute range length

Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue2690] Precompute range length

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue2690] Precompute range length

Mark Lawrence added the comment: @Nick, would you have time to work on this for 3.2, or should we target 3.3, or could somebody else take this over? -- nosy: +BreamoreBoy ___ Python tracker ___

[issue2690] Precompute range length

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

[issue2690] Precompute range length

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue2690] Precompute range length

Changes by Daniel Diniz : -- stage: -> patch review versions: +Python 3.2 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mail

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Given the problems with it, I'm dropping this to normal priority and punting to 3.1. (the release blocker status was just temporary to ensure we got a decision on it before rc1 - it previously didn't have a priority set) -- keywords:

[issue2690] Precompute range length

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I wonder if we shouldn't hold off on this. It's a substantial amount of new code. I'd be fine with it going into 3.0.1 since it's pure optimization (IIUC!). But right now we want burn-in, not new features. __

[issue2690] Precompute range length

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: By the way, why is this release blocker? do we have performance numbers? ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: v2 of my updated patch attached to fix the issue Antoine noted. Also gets rid of some tab-instead-of-spaces indenting issues in the file, and avoids hardcoding PyRange_Type when creating new instances. However, the patch still has issues, as c

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Good catch Antoine (I missed that in Alexander's patch) - working on that now. ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: My initial patch had a few problems - I removed it and uploaded a corrected version. Added file: http://bugs.python.org/file11346/issue2690-range-sequence-ncoghlan.diff ___ Python tracker <[EMAIL PROTECTED]

[issue2690] Precompute range length

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11345/issue2690-range-sequence-ncoghlan.diff ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2690] Precompute range length

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: It looks like your range_subscript() forgets to compute the length field... ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: This issue was missing a priority setting. Alexander's range-sequence patch still applies cleanly to the Py3k branch, and "make test" still runs correctly after applying it. As Alexander notes above, range_contains does still need slightly bet

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Guido, does that mean we can apply this patch to get the cleaner list-like behaviour for 3.0, and then work on the sq_item/sq_len fixes for 3.1 as a separate issue? ___ Python tracker <[EMAIL PROTECTED]>

[issue2690] Precompute range length

Guido van Rossum <[EMAIL PROTECTED]> added the comment: On the issue of whether len(range()) should be allowed to be > sys.maxsize, I think this should be allowed. I think in the future we should change the __len__ protocol to allow unbounded lengths. Even today, I think range(10**100).__len__(

[issue2690] Precompute range length

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Has a resolution been made on this? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2690] Precompute range length

Facundo Batista <[EMAIL PROTECTED]> added the comment: Fair enough, specially if in the documentation of range() we put "if you want a unbound, no limit, number generator, use itertools.count()" (or something well written in english ;) ). Thanks! __ Tracker <[EMA

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: It also isn't what range() and xrange() are used for now in 2.x. range() returns an actual list, hence is limited to sequences that fit in a reasonable amount of memory, and xrange() doesn't support values greater than sys.maxint at all (as it u

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: > For me, range() should mimic a number generator: no limit, no length. That's itertools.count() __ Tracker <[EMAIL PROTECTED]> __ _

[issue2690] Precompute range length

Facundo Batista <[EMAIL PROTECTED]> added the comment: My 2 cents: for me is more useful to have a unbound range() than to be able to do a len() on it. For me, range() should mimic a number generator: no limit, no length. -- nosy: +facundobatista __ Trac

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Reviewing my own patch (range-sequence.diff), I've realized that it is being a bit too clever in handling x in range(..) where x is not an integer. It seems that upon a failed PyLong_Check, range_contains should just do a linear sear

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I've implemented range slicing and x in range(..) in range-sequence.diff and registered range with the Sequence ABC. Added file: http://bugs.python.org/file10131/range-sequence.diff __ Tracker <[EMAIL P

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Given that range() produced a list in the 2.x series (hence limited to available memory), and xrange() uses int internally for its values (and hence couldn't even cope with short ranges with values greater than sys.maxint). So my preference is

[issue2690] Precompute range length

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Hmm, AFAIKT there is always at least one non-residue between 1 and p > and therefore you can just write > > for i in itertools.count(1): > if (i_is_a_nonresidue_modulo_p): > break > > maybe with an additional check for p > 1. S

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, Apr 25, 2008 at 4:37 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: .. > for i in range(1, p): > if (i_is_a_nonresidue_modulo_p): > break > > Here p might be a 200-digit prime number, and the situation is that half >

[issue2690] Precompute range length

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > What are the use cases for ranges with length greater than maxsize? Yeah---I'm a bit short on use cases. The one that originally bit me with Python 2.x was when I was doing a search for a quadratic non-residue modulo a largeish prime; f

[issue2690] Precompute range length

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I am currently working on a patch that allows large ranges and large indices. The trick is to define tp_as_mapping->mp_subscript. Then range_item() is rarely used, only by functions calling directly the PySequence_* functions, instead of

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Option (3) would require changing both sq_item and sq_length signatures, which is likely to have a large negative impact on performance. Option (2) would either require a change for the sq_length signature, or leave the problem of havin

[issue2690] Precompute range length

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I guess there needs to be a decision on whether to make range objects of length >= PY_SSIZE_T_MAX illegal; perhaps more discussion on python-dev would be worthwhile? I can see three options, besides leaving things as they are: (1) make lar

[issue2690] Precompute range length

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, Apr 25, 2008 at 12:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: .. > I don't much like this aspect of the change: there are uses for > > for i in range(ridiculously_large_number): For this application, I would use "for i

[issue2690] Precompute range length

Mark Dickinson <[EMAIL PROTECTED]> added the comment: So with this patch, range(10**100) produces an OverflowError: is that right? I don't much like this aspect of the change: there are uses for for i in range(ridiculously_large_number): ... if condition_that_occurs_early_in_practice:

[issue2690] Precompute range length

New submission from Alexander Belopolsky <[EMAIL PROTECTED]>: Attached patch makes range objects precompute their length on creation. This speeds up indexing and len at the expense of a small increase in range object size. The main benefit, however is that unsupported length > sys.maxsize is