find() vs index() vs `in` — which one?

They do the same search and differ only in how they report a miss. find returns -1, index raises ValueError, and in returns a bool. Pick by whether a miss is expected (use find or in) or a bug (use index).

Overview

The same search, three reports

find returns the index of the first occurrence, or -1. index returns the same index, or raises ValueError. in answers only yes or no, and reads better when that is all you need.

All three are the same O(n·m) scan underneath, so this is not a performance choice. There are rfind and rindex for the last occurrence, and all of them take optional start and end bounds — which is how you find the second occurrence without slicing.

StringsConceptualEasy

Step through it

What to watch

  • All three scan the same way — the difference is only at the end.
  • -1 is a valid index in Python, which is why find has a sharp edge.
  • if s.find(x): is a real bug — index 0 is falsy.

Say this out loud

"Same search, different failure. find gives -1, index raises, `in` gives a bool. If missing is normal I use find; if missing means something upstream is broken I use index so it fails loudly."

find() vs index() vs `in` — which one?

What is the difference between str.find and str.index, and when would you use each?

The trap in find's return value

-1 is a perfectly valid index in Python, so a find result used without checking silently indexes from the end. Worse:

if s.find("a"): is False when the match is at index 0 — the one case you were most likely to want. The check has to be if s.find("a") != -1:, which is exactly why in exists.

How to choose

Use in when you only need to know whether it is there. Use find when a miss is a normal outcome you will branch on. Use index when a miss means something upstream is already broken and you would rather have a traceback at the real cause than a -1 propagating three functions away.

That last point is the answer interviewers are listening for: it is a question about error handling wearing a string-methods costume.

Run it in Python

The three calls on a hit and on a miss, then the two bugs find invites — including the falsy-zero one, shown giving a confidently wrong answer.

find_index.pyPython 3
Output

How the code works

  1. s.find("zzz") -> -1A sentinel, not an error. Convenient when a miss is expected, and dangerous the moment the result is used without being checked.
  2. s[i] with i = -1Silently the last character. Python's negative indexing means a forgotten check does not crash — it returns something plausible, which is worse.
  3. if s.find(needle):False when the match is at index 0. The table shows it getting the first case wrong; the test has to be != -1.
  4. text.find("at", at + 1)The start bound walks through every occurrence without slicing, which would copy the remainder on each step.

Change one thing

  • Swap find for index in the loop and let it run off the end. The ValueError is the loop condition you forgot to write.
  • Use rfind to walk backwards. Same bounds, same sentinel, opposite direction.

Where this runs

Real CPython, compiled to WebAssembly and running on your own machine — nothing is uploaded. The first run takes a few seconds while the interpreter downloads; after that it is immediate. Need more room, or want to paste your own attempt? Use the Python compiler.

Check yourself

0 of 3

Answer without scrolling back up.

  1. s.index('zzz') when 'zzz' is absent:

  2. Why is `if s.find(x):` a bug?

  3. To find the second occurrence of a substring, the cheapest approach is:

Cheat sheet

find() vs index() vs `in` — which one?

They do the same search and differ only in how they report a miss. find returns -1, index raises ValueError, and in returns a bool. Pick by whether a miss is expected (use find or in) or a bug (use index).

INTERVIEW · vizlearn.in/interview/find-versus-index-on-strings.html

About the author

Ashish Jangra builds and maintains VizLearn. Every module here is written and the visualisation behind it hand-built, so the numbers in a readout come from the same code that draws the picture. Corrections are genuinely welcome and get priority over everything else — if a page states something wrong, or an animation misrepresents what the algorithm does, get in touch.