Hmm, interesting idea. Though, I'm also a big py-spy user and haven't had any problems using it with greenlets.

I have concerns about whether it's even reliably possible, though, because the frames that created the greenlet can have been exited while the greenlet is still alive. In the best case scenario, we would wind up keeping references to all those frames alive, preventing deallocating any objects referenced by them. That can be a serious problem. (I haven't worked through all the details, but worse scenarios could be anything from confusing/corrupted tracebacks to improper unwinding behaviour [exceptions, try/finally, context managers] or interpreter crashes.)

Here's a contrived example:

import greenlet
import psutil

def func():
    greenlet.getcurrent().parent.switch()

def creates_greenlet():
    l = list(range(500_000))
    g = greenlet.greenlet(func)
    g.switch()
    return g

mem_before = psutil.Process().memory_full_info()
glets = [creates_greenlet() for _ in range(100)]
mem_after = psutil.Process().memory_full_info()

print(mem_before)
print(mem_after)
print('mem delta', (mem_after.uss - mem_before.uss) / 1024 /1024, "MB")

In normal circumstances, this reports that it required 8MB of memory to run, and runs in <4s. If I capture the frame when the greenlet is started, memory usage balloons to nearly 2GB! (And runtime doubles because of GC overhead.)

Even if this were to prove reliably possible, and no one was concerned about keeping all those extra objects around, it would be a substantial behaviour change visible to users. Not just in things like traceback.print_stack() or sys._current_frames(), but I expect things like debuggers to be affected. So it's not something we could just slip in, it would need a major version bump.