Read a Python Traceback From the Bottom Up
The last line is the error you actually have; everything above it is how you got there. Reading it in the wrong order is why "obvious" bugs feel confusing.
Back in my undergrad CS courses, I remember staring at a wall of red traceback text after a Python script blew up, reading it top to bottom like a paragraph, and getting more lost with every line. It took a professor pointing out one thing to fix that: read a Python traceback from the bottom up, not the top down.
The last line of a traceback is the actual exception — the error type and message, like ValueError: invalid literal for int() with base 10: 'abc'. That's the thing that actually went wrong. Everything above it is the call stack that led there, printed in the order Python walked through it, which means the frame closest to the bottom is the one where the exception was actually raised, and the frames above that are the callers that got you there.
Reading top-down, you hit your own application code first — some function you wrote, calling another function you wrote — and it's easy to assume the bug lives right there, because that's the first thing you see. Reading bottom-up, you see the real error and the exact line that raised it first, then you trace backward through the calls that led to it only as far as you need to.
This matters even more once third-party libraries are in the stack. A traceback that passes through several layers of a library before reaching your code can look intimidating top-down, like the bug is buried deep in someone else's package. Read from the bottom, and you'll often find the actual raise statement is in your own code, or in a call you made with the wrong argument — the library frames above it are just how your bad input got passed along.
One more habit worth building on top of this: use raise ... from when you deliberately catch one exception and raise a different one, instead of just raising the new exception on its own. Python's own documentation on exception handling covers this directly — it chains the two automatically and shows both in the traceback, so whoever reads it later, often you, in six months, can see the original cause instead of just the exception you decided to surface.
None of this requires a different tool or a debugger session. It's just reading the same text in the order Python actually generated it, which is the opposite of how English reads and exactly why it trips people up the first several times.