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 cer
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
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
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
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
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 bette
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 answe
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() e
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
> >> generatio
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 P
>> 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
>> f
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
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
13 matches
Mail list logo
