[Python-Dev] PEP 3000 and exec (original) (raw)
Guido van Rossum guido at python.org
Mon Oct 17 17:49:44 CEST 2005
- Previous message: [Python-Dev] PEP 3000 and exec
- Next message: [Python-Dev] PEP 3000 and exec
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 10/17/05, Jim Jewett <jimjjewett at gmail.com> wrote:
Guido van Rossum wrote:
> Another idea might be to change the exec() spec so that you are > required to pass in a namespace (and you can't use locals() either!). > Then the whole point becomes moot. I think of exec as having two major uses: (1) A run-time compiler (2) A way to change the local namespace, based on run-time information (such as a config file). By turning exec into a function with its own namespace (and enforcing a readonly locals()), the second use is eliminated. Is this intentional for security/style/efficiency/predictability?
Yes, there are lots of problems with (2); both the human reader and the compiler often don't quite know what the intended effect is.
If so, could exec/eval at least
(1) Be treatable as nested functions, so that they can read the current namespace.
There will be a way to get the current namespace (similar to locals() but without its bugs). But it's probably better to create an empty namespace and explicitly copy into it only those things that you are willing to expose to the exec'ed code (or the things it needs).
(2) Grow a return value, so that they can more easily pass information back to at least a (tuple of) known variable name(s).
You can easily build that functionality yourself; after running exec(), you just pick certain things out of the namespace that you expect it to create.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] PEP 3000 and exec
- Next message: [Python-Dev] PEP 3000 and exec
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]