Logged In: YES 
user_id=4771

This is actually all expected behavior, although the test 5 
suprised me much at first, because there should be no 
difference at all between test 4 and test 5: the "in locals()" 
has no effect.  In fact, there is no difference.  You can add or 
remove "in locals()" in both tests 4 and 5 and it's always test 5 
(i.e. the second time the same test) that fails.  The reason is 
a bit subtle.

Specifying a globals in exec is "not recursive", so to say, 
because every function call executes the callee in the globals 
where it was originally defined.  These globals are attached to 
the function object (but not to the code object).  So tests 2 
and 3 (which are exactly equivalent) strip naked the code of 
greet and run it into a globals where it was not expected to 
be; it's as if you took the source code of the function and 
pasted it in place of the exec.  It finds globalvar in the current 
module, and it also finds show_globalvar() because you 
imported it in the line "from submod import *", but this calls 
the unmodified show_globalvar() in submod.py, hence the 
NameError.

If you wanted so-called recursive custom globals, all functions 
calls would have to be replaced by exec's.  I assume you know 
that using classes and instances looks like a much cleaner 
solution...

Now test 4 passes because it's as if you had pasted the whole 
source code of submod.py there.  In particular, you are 
creating a new version of all the functions, which live in the 
execprob module.  Now when test 5 runs, the expression 
'greet.__module__' has a new meaning: 'greet' is now the 
name of the function defined in the current module by the test 
4... so now 'greet.__module__' actually names the current 
module, and you're executing the current module recursively.