Repository navigation
Allow the f_func field of the _PyInterpreterFrame struct to be any object (and rename it) #96237
Closed as not planned
Description
Activity
Does it really need to allow any object? Could you instead define a small number of object types that it can be?
I don't see any advantage to restricting the possible types. Allowing any object is no worse for any code reading from
f_funcobjand more flexible for anything storing to it.Given the values of
f_globalsandf_builtinscan no longer be trusted, I think I'll make themvoid *just to make it clear that if you didn't set them, then you can't trust them.Reacted by Irit KatrielShould this issue be closed, given the attached PR was merged? Or is there more planned here?
Superseded by #100987
In order to better support shim frames, trampolines, Cython frames and other such bits and pieces, we need to relax the requirement that the
f_funcfield is a function.The only reason for it to be a function is that it needs to hold a strong reference to builtins and globals, as the frame only has a borrowed reference to those. Any object with those references will do.
In fact, for code that has no builtins or globals (many shims and trampolines) there is no need for those references and
f_funccould even beNone.