In Python 2.6 and 2.7, the same problem applies to xrange objects.

The attached patch adds the range.count and range.index methods.
Pseudocode for the two method:

def count(self, ob):
    if ob in self:
        return 1
    else:
        return 0

def index(self, ob, start=0, stop=len(self)):
    if ob in self:
        idx = (ob - self.start) // self.step
        if start < 0:
            start = start + len(self)
        if stop < 0:
            stop = stop + len(self)
        if start <= idx < stop:
            return idx
    raise ValueError("{!r} is not in range".format(ob))

Sorry, the previous patch has a reference leak. I'm attaching the fixed patch as issue9213a.diff (I also added a few tests with really big ranges).

I can’t comment on C code, but the tests look good to me.

I support adding index() and count() to range objects.

Thank you for the patch.

The patch doesn't handle the case where the object being searched for is !PyLong_CheckExact. For example, the user might pass in a sub-type of int. The existing range_contains supports that case, so it seems like we should support it in range_index and range_count.

The Sequence ABC's .index method doesn't include the optional start and stop parameters that are present on list.index. Since it's not part of the ABC, it's not mandatory that we implement those for range.index. The patch includes support for start and stop.

Attached is a greatly revised patch, with two significant changes:

• Adds support for !PyLong_CheckExact (using _PySequence_IterSearch)
• Drops support for the start and stop parameters to index

Dropping support for the start and stop parameters greatly simplified the code. If we want to support start and stop, then the code will need to get more complicated to handle the !PyLong_CheckExact case (since PySequence_IterSearch doesn't support start and stop).

My patch abstracts out most of the code that had originally been in range_contains into a new function range_contains_long so that it can be called by range_contains, range_count, and range_index. The diff makes that part look like a large change, but it's mostly a whitespace change (the refactored code lost one indentation level but is otherwise unchanged).

I uploaded Daniel Urban's patch and mine to Rietveld:
http://codereview.appspot.com/2146041/

Any strong feelings on whether range.index should support the start and stop arguments provided by list.index, tuple.index, and str.index, but not by collections.Sequence.index?

Attached is a greatly revised patch, with two significant changes:

• Adds support for !PyLong_CheckExact (using _PySequence_IterSearch)

Thanks, indeed, we should support that.

Any strong feelings on whether range.index should support the start and
stop arguments provided by list.index, tuple.index, and str.index, but
not by collections.Sequence.index?

I don't think that this is very important.

I'd like to have this in 3.2.

Thanks, Georg, for prodding. As a new committer, I have possibly been erring a little too far on the side of having my patches thoroughly reviewed before committing.

I'll commit the patch on Monday if no one raises objections (after re-testing, of course).

Committed as r84791.

Question: should this bugfix be backported to Python 3.1 and to xrange objects in Python 2.7? Since it's a bugfix that adds new methods, it's a gray-area. (same question applies to the closely related Issue bpo-9212)

I am -1 on adding new methods to builtins in bugfix releases.

Sounds reasonable to me. I'll close this and the related 9212 (both fixes are already committed to the py3k branch).