Mmm. Changing control flow based on introspection of the call stack is reasonably nasty.
I recall we found a neat use for call stack introspection in one project - not to change control flow but to improve logging. Inside an open_db_connection utility function, to auto-generate an informational name describing which part of the codebase had opened the connection:
E.g. some_backend_process: main -> ... > grandparent -> parent -> open_db_connection
We'd use information from the call stack generate a string "some_backend_process grandparent.parent" describing the call site which could be passed to postgres as the application_name [1] when establishing a connection. Then from the database side, if we had problematic queries at runtime, we had a lot more clues to figure out which part of the backend codebase was responsible [2].
There'd be a way to do something equivalent without peeking at the call stack, by requiring the caller to explicitly pass a descriptive & unique name, but that makes things a bit more error-prone, especially since some devs would be prone to copy-pasting chunks of existing code & reusing the same name everywhere.
Author here. I ran into this while comparing Pendulum with `whenever`, the datetime library I maintain. I sent a patch that removes the hack, but the post is about why the underlying design can't be patched the same way. Happy to answer questions.
> The trouble with guessing who’s calling is that you can’t anticipate every caller. Pendulum’s hard-coded check is fragile: it covers only one name, and relies on an exact call stack that Pendulum doesn’t control.
Edit: it looks like the later parts of the article show a lot of LLM tells, but not the beginning. I've been seeing this pop up more and more lately...
This is impressive, because I had no idea and now I feel angry at having my time wasted! If this type of stuff increases in frequency and I can't easily tell if an article is AI or not, I will stop reading them.
I can't provide any code samples, but this only strikes me as medium-cursed as far as python code goes. That stuff can get nasty! Once a team realizes they can modify anything at runtime things can go bad quite quickly.
I too have plumbed the call stack for hidden-maybe-forbidden knowledge from the caller, and it is always fraught. No matter how good one's intentions. Forget dynamic type testing. Forget Perl's `wantarray` dynamic introspection of "what does the caller want?" Those are small potatoes. This is full on "who's calling me and what do I want to send back as a result?" The people who will never forgive you for type testing are going to straight-up excommunicate whoever wrote this! And yet...it makes complete sense. Based on the promises made, you have to do something... and you're already in "what is the least of the evils?" territory, because you're going to have to do something that someone—maybe a lot of someones—will call evil.
My admiration for Pendulum just increased. This is sin-eating.
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?
I recall we found a neat use for call stack introspection in one project - not to change control flow but to improve logging. Inside an open_db_connection utility function, to auto-generate an informational name describing which part of the codebase had opened the connection:
E.g. some_backend_process: main -> ... > grandparent -> parent -> open_db_connection
We'd use information from the call stack generate a string "some_backend_process grandparent.parent" describing the call site which could be passed to postgres as the application_name [1] when establishing a connection. Then from the database side, if we had problematic queries at runtime, we had a lot more clues to figure out which part of the backend codebase was responsible [2].
There'd be a way to do something equivalent without peeking at the call stack, by requiring the caller to explicitly pass a descriptive & unique name, but that makes things a bit more error-prone, especially since some devs would be prone to copy-pasting chunks of existing code & reusing the same name everywhere.
[1] https://www.postgresql.org/docs/current/libpq-connect.html#L... [2] https://www.postgresql.org/docs/current/monitoring-stats.htm...
> The trouble with guessing who’s calling is that you can’t anticipate every caller. Pendulum’s hard-coded check is fragile: it covers only one name, and relies on an exact call stack that Pendulum doesn’t control.
Edit: it looks like the later parts of the article show a lot of LLM tells, but not the beginning. I've been seeing this pop up more and more lately...
By the end of that paragraph thereafter I started skimming as the rest turned blatantly LLM.
I should have caught the emdash in the first code block in "Who else is calling" though...
You didn't stop reading after "The hack itself is on its way out, but the design behind it still matters for your code"? I did.
Nice hack for maintaining old behavior tho!
I too have plumbed the call stack for hidden-maybe-forbidden knowledge from the caller, and it is always fraught. No matter how good one's intentions. Forget dynamic type testing. Forget Perl's `wantarray` dynamic introspection of "what does the caller want?" Those are small potatoes. This is full on "who's calling me and what do I want to send back as a result?" The people who will never forgive you for type testing are going to straight-up excommunicate whoever wrote this! And yet...it makes complete sense. Based on the promises made, you have to do something... and you're already in "what is the least of the evils?" territory, because you're going to have to do something that someone—maybe a lot of someones—will call evil.
My admiration for Pendulum just increased. This is sin-eating.
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?