Really support custom types for global namespace

13 views
Skip to first unread message

Robert Lehmann

unread,
Jun 17, 2014, 12:28:35 PM6/17/14
to python...@googlegroups.com
I'm not sure if this is a beaten horse;  I could only find vaguely related discussions on other scoping issues (so please, by all means, point me to past discussions of what I propose.)

The interpreter currently supports setting a custom type for globals() and overriding __getitem__.  The same is not true for __setitem__:

class Namespace(dict):
    def __getitem__(self, key):
        print("getitem", key)
    def __setitem__(self, key, value):
        print("setitem", key, value)

def fun():
    global x, y
    x  # should call globals.__getitem__
    y = 1  # should call globals.__setitem__

dis.dis(fun)
#  3           0 LOAD_GLOBAL              0 (x) 
#              3 POP_TOP              
#
#  4           4 LOAD_CONST               1 (1) 
#              7 STORE_GLOBAL             1 (y) 
#             10 LOAD_CONST               0 (None) 
#             13 RETURN_VALUE         

exec(fun.__code__, Namespace())
# => getitem x
# no setitem :-(

I think it is weird why reading global variables goes through the usual magic methods just fine, while writing does not.  The behaviour seems to have been introduced in Python 3.3.x (commit e3ab8aa) to support custom __builtins__.  The documentation is fuzzy on this issue:

If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object.

People at python-list were at odds if this was a bug, unspecified/unsupported behaviour, or a deliberate design decision.  If it is just unsupported, I don't think the asymmetry makes it any better.  If it is deliberate, I don't understand why dispatching on the dictness of globals (PyDict_CheckExact(f_globals)) is good enough for LOAD_GLOBAL, but not for STORE_GLOBAL in terms of performance.

I have a patch (+ tests) to the current default branch straightening out this asymmetry and will happily open a ticket if you think this is indeed a bug.

Thanks in advance,
Robert

Reply all
Reply to author
Forward
0 new messages