func_code vs. string problem

[Filip Dreger]

Uzytkownik "Steven Bethard" <steven.bethard at gmail.com> napisal w 
wiadomosci news:04mdnXLeedaPLvffRVn-vQ at comcast.com...

> See the documentation:
>
> http://docs.python.org/ref/dynamic-features.html
>
> """The eval(), execfile(), and input() functions and the exec 
> statement do not have access to the full environment for resolving 
> names. Names may be resolved in the local and global namespaces of 
> the caller. Free variables are not resolved in the nearest enclosing 
> namespace, but in the global namespace."""

Thank you! I feel silly I have not found the piece of instruction 
myself. And even worse, as I still do not understand: if exec() 
resolves free bariable names in the global namespace, how come it 
works well with code in a string? Or with a code in a compiled string?

> Note the last sentence, which tells you that your free variable, 
> 'abc', will be resolved in the *global* namespace.  In your 
> particular problem, you can solve this by substituting your local 
> namespace for the global namespace.

This particular problem - sadly - is a simplified version of the real 
one. I need access to both: global and local namespaces, so this 
solution is not for me.
The manual says I can pass two dictionaries to exec, one for global 
namespace and one for local. But, strange as it seems, I could not get 
it to work. In the example I gave, changing exec f.func_code to exec 
f.func_code in globals(),locals() does not help a bit.

> One possible workaround might be:
>
> py> class foo:
> ...     def test(self):
> ...         print "ABC"
> ...     def checkfunction(self):
> ...         abc=10
> ...         l = locals()
> ...         l.update(globals())
> ...         exec myfunction.func_code in l
> ...     def checkstring(self):
> ...         abc=10
> ...         exec "print abc;self.test()"
> ...
> py> foo().checkfunction()
> __main__.foo
> 10
> ABC

I thought about that... I don't know why, but it seems wrong. Maybe 
the updating dictionaries is not very expensive, but there must be 
some better way. This code has a 'workaround - fixme' written all over 
it.
Up to now, each time I encountered such a workaroundish solution, it 
turned out Python has a cleaner way to do it. I sure hope this is also 
the case here :-).

> But I'd have to know what your real use case is to tell you whether 
> or not this is worth the trouble.  Why do you want to exec the 
> func_code anyway?  Why can't you just call the function?

I put the description in the other post. Perhaps it's jkust my design 
that's broken.
Thanks again.

regards,
Filip Dreger