[Python-Dev] PEP 3000 and exec
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? If so, could exec/eval at least (1) Be treatable as nested functions, so that they can *read* the current namespace. (2) Grow a return value, so that they can more easily pass information back to at least a (tuple of) known variable name(s). -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
On 10/17/05, Jim Jewett [EMAIL PROTECTED] 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/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and exec
For communicating with an exec/eval child, once exec cannot run in the current namespace, I asked that it be possible to pass a read-only current view and to see a return value. (Guido): ... it's probably better to create an empty namespace and explicitly copy into it ... ... just pick certain things out of the namespace [afterwards] Yes and no. If the exec'ed code is well defined (and it needs to be if security is a concern), then that works well. For more exploratory code, it can be hard to know what in advance what the code will need, or to agree on the names of return variables. The simplest general API that I can come up with is You're allowed to see anything I can (even if it is in a nested scope or base class, and I realize that you *probably* won't need it). Return value is whatever you explicitly choose to return (Lisp's last result might be even simpler, but would probably lead to confusion other places.) -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and exec
Agree. i=1 def a(): i=2 def b(): print i return b a()() 2 def a(): i=2 def b(): exec print i return b a()() 1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
Guido van Rossum wrote: My idea was to make the compiler smarter so that it would recognize exec() even if it was just a function. 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 vote for the latter option. Particularly if something like Namespace objects make their way into the standard lib before Py3k (a Namespace object is essentially designed to provide attribute style lookup into a string-keyed dictionary- you can fake it pretty well with an empty class, but there are a few quirks with doing it that way). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and exec
This might be minor-- but I didn't see anyone mentioning it so far. If `exec` functionality is to be provided, then I think it still should be a keyword for the parser to know; currently bytecode generation is affected if `exec` is present. Even if that changes for Python 3k (we don't know yet), the paragraph for exec should be annotated with a note about this issue. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
On 10/10/05, Christos Georgiou [EMAIL PROTECTED] wrote: This might be minor-- but I didn't see anyone mentioning it so far. If `exec` functionality is to be provided, then I think it still should be a keyword for the parser to know; currently bytecode generation is affected if `exec` is present. Even if that changes for Python 3k (we don't know yet), the paragraph for exec should be annotated with a note about this issue. But the PEP says that 'exec' will become a function and thus no longer become a built-in, so changing the grammar is not needed. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
This might be minor-- but I didn't see anyone mentioning it so far.
If `exec` functionality is to be provided, then I think it still
should be a keyword for the parser to know; currently bytecode
generation is affected if `exec` is present. Even if that changes
for Python 3k (we don't know yet), the paragraph for exec should be
annotated with a note about this issue.
Brett But the PEP says that 'exec' will become a function and thus no
Brett longer become a built-in, so changing the grammar is not needed.
I don't think that was the OP's point though it might not have been terribly
clear. Today, the presence of the exec statement in a function changes how
non-local load instructions are generated. Consider f and g with their
dis.dis output:
def f(a):
... exec import %s % a
... print q
...
def g(a):
... __import__(a)
... print q
...
dis.dis(f)
2 0 LOAD_CONST 1 ('import %s')
3 LOAD_FAST0 (a)
6 BINARY_MODULO
7 LOAD_CONST 0 (None)
10 DUP_TOP
11 EXEC_STMT
3 12 LOAD_NAME1 (q)
15 PRINT_ITEM
16 PRINT_NEWLINE
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
dis.dis(g)
2 0 LOAD_GLOBAL 0 (__import__)
3 LOAD_FAST0 (a)
6 CALL_FUNCTION1
9 POP_TOP
3 10 LOAD_GLOBAL 2 (q)
13 PRINT_ITEM
14 PRINT_NEWLINE
15 LOAD_CONST 0 (None)
18 RETURN_VALUE
If the exec statement is replaced by a function, how will the bytecode
generator know that q should be looked up using LOAD_NAME instead of
LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
on the wiki page might be worthwhile.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
My idea was to make the compiler smarter so that it would recognize
exec() even if it was just a function.
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.
On 10/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This might be minor-- but I didn't see anyone mentioning it so far.
If `exec` functionality is to be provided, then I think it still
should be a keyword for the parser to know; currently bytecode
generation is affected if `exec` is present. Even if that changes
for Python 3k (we don't know yet), the paragraph for exec should be
annotated with a note about this issue.
Brett But the PEP says that 'exec' will become a function and thus no
Brett longer become a built-in, so changing the grammar is not needed.
I don't think that was the OP's point though it might not have been terribly
clear. Today, the presence of the exec statement in a function changes how
non-local load instructions are generated. Consider f and g with their
dis.dis output:
def f(a):
... exec import %s % a
... print q
...
def g(a):
... __import__(a)
... print q
...
dis.dis(f)
2 0 LOAD_CONST 1 ('import %s')
3 LOAD_FAST0 (a)
6 BINARY_MODULO
7 LOAD_CONST 0 (None)
10 DUP_TOP
11 EXEC_STMT
3 12 LOAD_NAME1 (q)
15 PRINT_ITEM
16 PRINT_NEWLINE
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
dis.dis(g)
2 0 LOAD_GLOBAL 0 (__import__)
3 LOAD_FAST0 (a)
6 CALL_FUNCTION1
9 POP_TOP
3 10 LOAD_GLOBAL 2 (q)
13 PRINT_ITEM
14 PRINT_NEWLINE
15 LOAD_CONST 0 (None)
18 RETURN_VALUE
If the exec statement is replaced by a function, how will the bytecode
generator know that q should be looked up using LOAD_NAME instead of
LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
on the wiki page might be worthwhile.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
On 10/11/05, Guido van Rossum [EMAIL PROTECTED] wrote: My idea was to make the compiler smarter so that it would recognize exec() even if it was just a function. 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 that's a great idea. It goes a step towards a more analyzable Python, and really, I've never found a *good* use case for allowing this invisible munging of locals. I would guess that it would simplify the implementation, given that there are currently so many special cases around exec, including when used with nested scopes. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
Brett Cannon wrote: But the better answer is we will just find a way. =) I think the best answer would be just to dump the idea of exec-in-local-namespace altogether. I don't think I've ever seen a use case for it that wasn't better done some other way. Most often it seems to be used to answer newbie variable variable questions, to which the *correct* answer is invariably start thinking in Python, not bash/perl/tcl/PHP/ whatever. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and exec
On 10/10/05, Greg Ewing [EMAIL PROTECTED] wrote: Brett Cannon wrote: But the better answer is we will just find a way. =) I think the best answer would be just to dump the idea of exec-in-local-namespace altogether. I don't think I've ever seen a use case for it that wasn't better done some other way. I agree that 'exec' could really stand to be tweaked. As it stands now it is nasty to deal with when it comes to program analysis. Anything that will make that easier gets my vote. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
