[pypy-dev] bug with vars() in a nested function

Alex Martelli aleaxit at yahoo.com
Mon Dec 22 22:23:24 CET 2003


The implementation of vars() in builtin.py relies on a call to getdictscope() 
to return the caller's locals as a dir, but unfortunately that doesn't work 
when the caller of built-in vars() is a nested function -- nestedscope.py
overrides fast2locals to ensure setting in self.w_locals the free variables
in addition to the locals, and that w_locals is what getdictscope returns.

Apparently this kind of bug must have bitten CPython at some point (or
at least be suspected!) since the unit-test for vars() looks for it pretty
exactly (that's how I found it, too -- still striving to run as much of that
CPython unit-test as feasible!) -- basically, it has something like:

        def test_vars(self):
            def get_vars_f0():
                return vars()
            def get_vars_f2():
                get_vars_f0()
                a = 1
                b = 2
                return vars()
            ...
            self.assertEqual(get_vars_f2(), {'a': 1, 'b': 2})

where that 'useless' call to get_vars_f0 inside get_vars_f2 serves just
the purpose of "infecting" the latter with the former name -- and sure
enough the assertEqual fails because 'get_vars_f0' is reported as being
a key in the dict returned by get_vars_f2().

My instinct is to patch this with an optional switch to getdictscope to
ask for "return the TRUE locals only please" -- but since a vaguely
analogous patch I had tried to remedy the issue with generators raising
StopIteration (i.e. "directly attacking the symptom rather than going for
a more general solution") was criticized, I thought I'd better ask first 
rather than committing anything yet -- this one IS a rather marginal and
obscure side issue after all, so for now I'll just mark it as 'XXX TODO'
and comment it away in the builtin_functions_test.py file (what's one
more...).

Which reminds me: do we have a "known bugs" file/summary, or are
the infos about known bugs, limitations &c spread around in comments
and docstrings?  'cause the XXX TODO in the builtin_*_test.py files
are quite a nifty list of known current bugs and limitations for built-ins,
so I wondered if I should collect them in some documentation file...


Alex



More information about the Pypy-dev mailing list