Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upbpo-36220: STORE_GLOBAL: Support dict subclasses for globals. #18033
Conversation
If globals are not concrete `dict` type, use PyObject_SetItem() on it,
instead of PyDict_SetItem(). This is similar how STORE_NAME deals
with locals already. (And also similar to how some (but not all)
LOAD_* opcodes deal globals/locals),
Given that on the module level, locals and globals are the same,
this change fixed the situation when:
exec("foo = 1", my_globals)
and
exec("global foo; foo = 1", my_globals)
(where "my_globals" is a dict subclass, intended to trace namespace
operations)
lead to different behavior, where in first case, my_globals.__setitem__()
is called (because STORE_NAME opcode is generated), while in second case,
it's not called (because STORE_GLOBAL is generated).
Note that this change is not related in any way to security sandboxing
(in a sense that this change doesn't make any claims in regard to
improvements to such secuirty sandboxing matters). Instead, it's intended
to make the light-weight instrumentation of Python code for generic
purposes more consistent and predictable (e.g. to collect statistics,
profile code, etc).
|
There is no agreement in the issue about this, so I will mark it as For reference, the discussion is happening at: |
This comment has been minimized.
This comment has been minimized.
bedevere-bot
commented
Jan 16, 2020
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
This comment has been minimized.
This comment has been minimized.
|
Sure, it's just to show that the patch is trivial (and fully mirrors code in STORE_NAME), and to further the argument that it's to achieve consistency both with the behavior of STORE_NAME, and consistency of the behavior of 2 exec calls, where difference is only in "global" declaration of the var used in one exec(). |
pfalcon commentedJan 16, 2020
•
edited by bedevere-bot
If globals are not concrete
dicttype, use PyObject_SetItem() on it,instead of PyDict_SetItem(). This is similar how STORE_NAME deals
with locals already. (And also similar to how some (but not all)
LOAD_* opcodes deal globals/locals),
Given that on the module level, locals and globals are the same,
this change fixed the situation when:
exec("foo = 1", my_globals)
and
exec("global foo; foo = 1", my_globals)
(where "my_globals" is a dict subclass, intended to trace namespace
operations)
lead to different behavior, where in first case, my_globals.setitem()
is called (because STORE_NAME opcode is generated), while in second case,
it's not called (because STORE_GLOBAL is generated).
Note that this change is not related in any way to security sandboxing
(in a sense that this change doesn't make any claims in regard to
improvements to such secuirty sandboxing matters). Instead, it's intended
to make the light-weight instrumentation of Python code for generic
purposes more consistent and predictable (e.g. to collect statistics,
profile code, etc).
https://bugs.python.org/issue36220