You could simply store a reference to the caller's frame object, but this is probably a bad idea. This keeps the frames alive, and also holds references to all the local variables used, so it may impact performance if they happen to be using large chunks of memory, and could have even worse effects if they're relying (incorrectly) on finalization to destroy resources like locks and filehandles when they go out of scope.
That means you'd need to hold a string representation of the stacktrace instead, which is not ideal for your purposes (need to actually do some processing to get it, even though it's rarely needed). Unfortunately, there doesn't seem to be much way around this, though you could consider disabling it until you set some configuration option. That way you'd get better performance for the common case, but could still enable the setting when trying to diagnose failures.
If your calling function alone (or some small number of parent callers) is enough to distinguish the route (ie. the trace is always the same when called via func1(), and there's no func2 -> func1() vs func3() -> func1() to distinguish between ), you could maintain a hash based on filename and line number of the calling frame (or the last two calling frames etc). However this probably doesn't match your situation, and where it doesn't, you'd end up with bogus stack traces.
Note that if you do want the caller's frame, using inspect.currentframe(depth)
is probably a better way to get it.