There is an unjustified asymmetry between `str` and `list`, as far as lookup goes. Both have an `index()` method that returns the first index of a value, or raises a `ValueError` if it doesn't exist. However, only `str` has the `find` method, which returns -1 if the value is not in the string.

I think it would make sense to add `find` to `list` as well. For starters, it would make the API between the two sequence types more consistent. More importantly (though it depends on the use-case), `find` is usually more convenient than `index`, as one doesn't have to worry about handling an exception. As a bonus, since `list` is mutable, it allows one to write code such as

    if (idx := lst.find(value)) == -1:
        lst.append(value)
    call_some_function(lst[idx])

, making the method even more useful as it is in `str`.

Strings are already special in that str.index() and str.find() both find substrings, while list.index() only finds a single element.

If .find() also searched for a substring of the list, I think this could be helpful. Even more so if it used an efficient algorithm (bearing in mind that the arbitrary comparisons between elements - something else that doesn't exist in strings - would make this complicated).

This is probably something to bring up on the python-ideas mailing list first, anyway. Symmetry is not a sufficient reason in itself to add new APIs - often the asymmetry exists because the "missing" one is only there for legacy/compatibility reasons, not because it is a good API.

This is one bit of symmetry that we shouldn't pursue.  The find() methods have been a recurring source of bugs because of failing to check for a -1 result but having that be a valid index into the sequence.

Also, the sequence APIs are long established.  If find() were really needed, we would have felt the pain and added it long ago.

As Steve says, you can take this to python-ideas, but my recommendation is to not do it all.