My understanding as per the outline in PEP 551 as well as PEP 578, is that the audit system is meant primarily to observe the behavior of code rather than to have good sandbox coverage / directly prevent behavior.

I am using audit hooks to observe the behavior of third party Python, and I identified an indicator of shady behavior which includes code and frame object access (which includes sys._getframe(), and __code__, both of which are part of the original PEP 578).

I looked into it further and realized the CPython's auditing for those attributes/objects is superficial. I understand that auditing isn't perfect, and I'm not trying to change that. This patch just seems to me like a really basic and obvious extension of the existing __code__ and getframe audit points.

----

I ask that if your main hesitation is the impact of future audit hooks, we use this opportunity to establish a basic written precedent we can reference in the future about which kind of audit hook modifications are likely to be accepted without, say, another PEP.

One possible set of criteria:
 - The added hooks should be justified as functionally identical to something the existing PEP(s) suggested.
 - Performance should be measured and it should have very little impact on stdlib or general code.
 - The requester should be expected to justify the change, e.g. how it closes an obvious gap in an existing PEP 578 hook.

And my answers for those criteria:
 - These are functionally equivalent to the existing PEP 578 hooks for sys._getframe() and function.__code__ - they operate on similar types of objects and are used for accessing the exact same information.
 - Performance impact here appears to be only for debugging code, and performance impact on debugging code is infinitesimal when no audit hook is active.
 - I am auditing code for trivial usage of Python frames and code objects, and I can't do that sufficiently with the existing hooks (especially so now that I'm publicly documenting this gap).

----

If the primary complaint is maintenance burden, would it be preferable to add an attribute audit flag to PyMemberDef instead of using one-off PyGetSetDef functions? e.g.:

static PyMemberDef frame_memberlist[] = {
    {"f_code",          T_OBJECT,       OFF(f_code),      READONLY|AUDIT_ACCESS},
}

That would definitely simplify the implementation.

If these additions aren't worth it, I would almost recommend removing or deprecating the existing __code__ and sys._getframe() audit hooks instead, as I find them to be not very useful without this patch.