Re: Some python comments/questions
lance@markv.com
Wed, 13 Oct 93 9:15:47 PDT
> > I often get bitten by this. Would it be possible to let eval() set
> > some flag or something whereby either the compiler or the runtime code
> > would stop accessing local variable the cheap way, but go through the
> > dictionary instead?
>
> I walked over to Jack's office to explain why this wasn't a good idea,
> and in the ensueing discussion we suddenly came up with the following
> solution: make exec a statement instead of a function. The syntax
> would be
>
> exec <expression> [in <expression> [, <expression>]]
>
> and the compiler can switch off any optimizations for functions
> containing exec statements. There is a precedent for this: the same
> happens when the compiler sees "from <module> import *", because it
> can't tell what local variables the star will introduce.
>
> The change will break some existing Python code: statements calling
> exec() with an explicit global and/or local dictionary. The majority
> of exec() function calls will still work since the extra parentheses
> are harmless.
>
> How about it?
PLEASE DON'T!!!!! I have a bunch of code that relies on passing in
explicit local and global dictionaries!!
My code does the following:
co = code object loaded from a file using marshal.load()
l_ns = {}
exec(co,{},l_ns)
exec(co,l_ns,l_ns)
I then call functions as:
l_ns['function_name'](args)
Each l_ns is a completely seperate name space and seperate environment!
I need this! Please don't take it away! Or tell me a better way to do it.
--
Lance Ellinghouse lance@markv.com
1231 bit key fingerprint = 56 DA 31 0C 17 51 36 6A 4E D4 E0 11 D9 B8 06 0A
1024 bit key fingerprint = 66 2C 75 F2 E9 1C 32 84 3A E3 B0 5E 48 01 4C 37
You can receive my Public Key by `finger lance@markv.com`