Another cursed approach here that avoids stack walking, but is almost as bad:

Say you want to rely on a library superclass's foo() implementation, and add some pre/post-processing logic... but in turn that superclass calls another self.bar() (or recurses into self.foo()) and you want to route that to the superclass rather than to self.

One possibility: copy in the superclass implementation and change the call sites. But now you lose the ability to get new features from the superclass if the library makes updates/bugfixes.

Another possibility, as the author suggests: make a new object that's just the superclass, have it run its logic, and bring in the state. But maybe the state itself is massive, or otherwise not something you want to copy (say, there's some kind of RAII).

Another possibility: fork the library, put your fork on a package manager, and have an AI agent maintain your fork for you, forever and ever and ever.

The cursed/blursed possibility: set a flag in a threading.local() that we're currently processing foo(). Superclass ignores this. But when we get to our other logic, we check self._mybrand_processing_locals and route accordingly.

At the end of the day, the stack state is just a threading.local(). Why not cut out the middleman? /s