On 18/07/2006 7:22 PM, Paul Boddie wrote: > John Machin wrote: >> On 18/07/2006 12:41 PM, [EMAIL PROTECTED] wrote: >>> it seems that range() can be really slow: > > [...] > >> Some things to try: >> 1a. Read what the manual has to say about the range() function ... what >> does it produce? > > Indeed. Still, the addition of a __contains__ method to range (and > xrange) would permit acceptable performance for the code given. Perhaps > this is a convenience worth considering for future Python releases. >
range() and xrange() are functions. You are suggesting that 2 *functions* should acquire a __contains__ method each? I trust not. Perhaps you meant that the acquisitors should be the objects that those functions return. range() returns a list. Lists already have a __contains__ method. It's been getting a fair old exercising in the last few hours, but here we go again: >python -mtimeit -s"x=range(30000)" "x.__contains__(40000)" 1000 loops, best of 3: 1.09 msec per loop >python -mtimeit -s"x=range(30000)" "40000 in x" 1000 loops, best of 3: 1.09 msec per loop >python -mtimeit -s"x=range(30000)" "x.__contains__(1)" 1000000 loops, best of 3: 0.434 usec per loop >python -mtimeit -s"x=range(30000)" "1 in x" 1000000 loops, best of 3: 0.137 usec per loop A __contains__ method for xrange objects? The case of x in xrange(lo, hi) is met by lo <= x < hi. IMHO, anyone who wants x in xrange(lo, hi, step) should be encouraged to do the necessary algebra themselves; I wouldn't suggest that any core dev time be wasted on implementing such folderol. In any case, isn't the *whole* xrange gizmoid on GvR's I-wish-I-hadn't list? Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
