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