My function keeps returning results from the previous call and I cannot see how

The default value is created once, when the def line runs, not each time you call the function. So there is exactly one list living on the function object, and every call that does not pass its own list appends to that same one. The fix is the None sentinel: take rows=None as the default, and on the first line of the body do rows = [] if rows is None else rows. Same trap applies to dicts, sets and anything else mutable you put in a default.

Worth knowing that a linter catches this before you ever run it. Ruff and flake8 with the bugbear rules both flag a mutable default argument as a specific warning, and it takes about a minute to add to a project. The category of bug that a linter finds is small but it is entirely free, and this one is the flagship member of that category.

I lost most of an evening to this exact shape of bug in a script that appended parsed records, and what made it so slow to find was that the first run was always right. I kept restarting the interpreter to test, which reset the default list, so the bug vanished every time I looked at it. If you are ever debugging something that only misbehaves on repeat calls, suspect state that outlives the call.

Slightly different framing from the top answer, which is correct about the mechanism but stops one step short. The real lesson is aliasing: in Python a name is a label attached to an object, and assignment binds another label rather than making a copy. Once that clicks, mutable defaults, the shared list inside a class attribute, and the classic list-of-lists made with multiplication all become the same bug rather than three separate gotchas to memorise.