[Python-3000] optimizing [x]range

[Guido van Rossum]

On 7/29/07, tomer filiba <tomerfiliba at gmail.com> wrote:
> i understand there is no much need for using ranges instead of
> intervals (a < x < b), but:
>
> 1) it's already supported. you CAN use x in range(100), so
> why not optimize it? there's no justification to keep it an
> O(N) operation (you're not trying to punish anyone :).
> it just calls for adding a __contains__ slot to range objects.
> the cost is very minimal.

Don't forget the *cost* in terms of code bloat. Plus, I asked for a
patch. Where is it? This is not Santa Claus's email address. You're
expected to contribute more than a wish.

> 2) ranges are more like set-builder notation, i.e.
> evens = {2*n | n in N}
> which can be written as
> evens = range(0, maxint, 2)
> odds = range(1, maxint, 2)
> you cannot phrase "x in odds" in "a <= x < b" notation.
> sure, just use modulu, but then it just gets ugly.

Um, your range "solution" would break for examples like 2**100 in
evens (it's hard to think of a more even number than that. :-)

Typically one would write a predicate that tested for modulo.

> if range (== xrange) would be a cheap, O(1) operation, there's
> not reason to to use it when it suits well.

But I still see no reason to make it O(1).

> -tomer
>
> On Jul 29, 12:04 am, "Guido van Rossum" <gu... at python.org> wrote:
> > Do we really need another way to spell a <= x < b? Have you got a
> > real-world use case in mind for the version with step > 1?
> >
> > I'm at most lukewarm; I'd be willing to look at a patch to the C code
> > in the py3k-struni branch, plus unit tests though.
> >
> > --Guido
> >
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)