You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Inconsistency in whether function setters call _PyFunction_SetVersion #109998
The function object has a number of settable attributes. For the following, setting the value calls _PyFunction_SetVersion(op, 0):
__defaults__
__kwdefaults__
__code__
__annotations__
But for the following, there is no such call:
__dict__
__name__
__qualname__
__type_params__
I don't think any of these four should affect the interpreter loop, but neither should __annotations__. Should these setters also set the version for consistency, or should __annotations__ not set it as changing the annotations shouldn't affect the runtime?
The func_version field is intended for use by the PEP 659 adaptive specializing interpreter and the Tier 2 optimizer (and JIT) only. You're right that the fields in the second list (as well as "plain" function attribute assignments like f.foo = 42) don't affect the specializer at all. You're also right that __annotations__ doesn't affect it! IMO that attribute should not call _PyFunction_SetVersion(); I think the call was added by mistake.
Separately, I think that the specializer should just not bother picking a new version for functions which have a "critical" attribute (the first list, less __annotations__) changed. Setting those is pretty obscure, and I think it's fine if the interpreter falls back to unspecialized Tier 1 bytecode for those cases. We could do that by changing _PyFunction_GetVersionForCurrentState() to just leave it zero. (Or just get rid of that function and use func->func_version directly in the specializer.)
TBH, I would also be open to making the critical attributes read-only, although I suspect that PyTorch might be using this feature (and then the idea would be dead on arrival).
Activity
gvanrossum commentedon Mar 18, 2024
The
func_versionfield is intended for use by the PEP 659 adaptive specializing interpreter and the Tier 2 optimizer (and JIT) only. You're right that the fields in the second list (as well as "plain" function attribute assignments likef.foo = 42) don't affect the specializer at all. You're also right that__annotations__doesn't affect it! IMO that attribute should not call_PyFunction_SetVersion(); I think the call was added by mistake.Separately, I think that the specializer should just not bother picking a new version for functions which have a "critical" attribute (the first list, less
__annotations__) changed. Setting those is pretty obscure, and I think it's fine if the interpreter falls back to unspecialized Tier 1 bytecode for those cases. We could do that by changing_PyFunction_GetVersionForCurrentState()to just leave it zero. (Or just get rid of that function and usefunc->func_versiondirectly in the specializer.)TBH, I would also be open to making the critical attributes read-only, although I suspect that PyTorch might be using this feature (and then the idea would be dead on arrival).
gvanrossum commentedon Mar 18, 2024
PS.
__closure__also belongs in the "critical" list. (And it does call_PyFunction_SetVersion().)gh-117045: Add code object to function version cache (#117028)
pythongh-117045: Add code object to function version cache (python#11…
Squashed commit of the following:
Squashed commit of the following:
pythongh-117045: Add code object to function version cache (python#11…