The trunk patch is also unacceptable in its current form:

 1. there are no docs or tests
 2. keyval, start, step and end should have type long, not type int
    (as Antoine already mentioned)
 3. the expression ((keyval - start) % step) can overflow, leading to
    undefined behaviour (e.g., wrong results, segfaults, strange
    effects from gcc optimizations that assume no overflow).  For
    example, with the patch, on Linux/x86-64, I get:

      >>> x = xrange(-2000000000, 2000000000, 5)
      >>> 1000000000 in x
      False

    This should be relatively easy to fix:  e.g., if you already
    know that step > 0 and start <= keyval and keyval < stop, then
    '(unsigned long)keyval - (unsigned long)start'  is safe from
    overflow.

 4. the containment check only works for ints:  with the patch, I get:

      >>> x = xrange(10)
      >>> 4 in x
      True
      >>> 4L in x
      False
      >>> 4.0 in x
      False

    but without the patch applied, all these return True.  It's possible
    that it's worth special-casing integer inputs for the sake of
    speed, but I don't think the behaviour should change like this for
    other types.