Ethan Furman wrote:
Ethan Furman wrote:
Ian Kelly wrote:
I am not a dev, but I believe it works because assigning to locals()
and assigning via exec are not the same thing. The problem with
assigning to locals() is that you're fundamentally just setting a
value in a dictionary, and even though
On Wed, 01 Feb 2012 14:53:09 -0800, Ethan Furman wrote:
> Indeed -- the point to keep in mind is that locals() can become out of
> sync with the functions actual variables. Definitely falls in the camp
> of "if you don't know *exactly* what you are doing, do not play this
> way!"
And if you *do*
Ian Kelly wrote:
Sure, but that's not actually out of sync. The argument of your exec
evaluates to 'print (a)'. You get two different results because
you're actually printing two different variables.
Ah -- thanks, I missed that.
You can get the dict temporarily out of sync:
def f(x, y):
Ian Kelly wrote:
On Wed, Feb 1, 2012 at 4:41 PM, Ethan Furman wrote:
I'm not sure what you mean by temporary:
--> def f(x, y):
... frob = None
... loc = locals()
... loc[x] = y
... print(loc)
... print(locals())
... print(loc)
... print(locals())
...
-->
--> f('fro
On Wed, Feb 1, 2012 at 4:41 PM, Ethan Furman wrote:
> I'm not sure what you mean by temporary:
>
> --> def f(x, y):
>
> ... frob = None
> ... loc = locals()
> ... loc[x] = y
> ... print(loc)
> ... print(locals())
> ... print(loc)
> ... print(locals())
> ...
> -->
> -->
Ian Kelly wrote:
On Wed, Feb 1, 2012 at 3:24 PM, Ethan Furman wrote:
Definitely should rely on it, because in CPython 3 exec does not un-optimize
the function and assigning to locals() will not actually change the
functions variables.
Well, the former is not surprising, since exec was changed
Ethan Furman wrote:
Ian Kelly wrote:
I am not a dev, but I believe it works because assigning to locals()
and assigning via exec are not the same thing. The problem with
assigning to locals() is that you're fundamentally just setting a
value in a dictionary, and even though it happens to be the
On Wed, Feb 1, 2012 at 3:53 PM, Ethan Furman wrote:
> --> def f(x, y):
>
> ... locals()[x] = y
> ... print(vars())
> ... exec('print (' + x + ')')
> ... print(x)
> ...
> --> f('a', 42)
>
> {'y': 42, 'x': 'a', 'a': 42}
> 42
> a
>
> Indeed -- the point to keep in mind is that locals(
Ian Kelly wrote:
I am not a dev, but I believe it works because assigning to locals()
and assigning via exec are not the same thing. The problem with
assigning to locals() is that you're fundamentally just setting a
value in a dictionary, and even though it happens to be the locals
dict for the
On Wed, Feb 1, 2012 at 3:24 PM, Ethan Furman wrote:
> Definitely should rely on it, because in CPython 3 exec does not un-optimize
> the function and assigning to locals() will not actually change the
> functions variables.
Well, the former is not surprising, since exec was changed from a
stateme
On Wed, Feb 1, 2012 at 11:47 AM, Mel Wilson wrote:
> I guess they want local symbols in functions to be pre-compiled. Similar to
> the way you can't usefully update the dict returned by locals(). Strangely,
> I notice that
>
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
> [GCC 4.4.3] on lin
Dave Angel wrote:
> I tried your experiment using Python 2.7 and Linux 11.04
>
>
> def f(a):
> from math import sin, cos
> return sin(a) + cos(a)
>
> print f(45)
>
> Does what you needed, and neatly. The only name added to the global
> namspace is f, of type function.
>
> I was a b
Am 01.02.2012 18:36, schrieb Dave Angel:
> def f(a):
> from math import sin, cos
> return sin(a) + cos(a)
>
> print f(45)
>
> Does what you needed, and neatly. The only name added to the global
> namspace is f, of type function.
I recommend against this approach. It's slightly slower an
On Wed, Feb 1, 2012 at 9:11 AM, Olive wrote:
> I am learning python and maybe this is obvious but I have not been able
> to see a solution. What I would like to do is to be able to execute a
> function within the namespace I would have obtained with from
> import *
>
> For example if I write:
>
On 02/01/2012 12:11 PM, Olive wrote:
I am learning python and maybe this is obvious but I have not been able
to see a solution. What I would like to do is to be able to execute a
function within the namespace I would have obtained with from
import *
For example if I write:
def f(a):
re
Olive wrote:
I am learning python and maybe this is obvious but I have not been able
to see a solution. What I would like to do is to be able to execute a
function within the namespace I would have obtained with from
import *
For example if I write:
def f(a):
return sin(a)+cos(a)
I c
On Feb 1, 11:11 am, Olive wrote:
> But I have polluted my global namespace with all what's defined in
> math. I would like to be able to do something like "from math import *"
> at the f level alone.
Seeing is believing!
>>> dir()
['__builtins__', '__doc__', '__name__', '__package__']
>>> from
On Wed, Feb 1, 2012 at 9:11 AM, Olive wrote:
> I am learning python and maybe this is obvious but I have not been able
> to see a solution. What I would like to do is to be able to execute a
> function within the namespace I would have obtained with from
> import *
>
> For example if I write:
>
I am learning python and maybe this is obvious but I have not been able
to see a solution. What I would like to do is to be able to execute a
function within the namespace I would have obtained with from
import *
For example if I write:
def f(a):
return sin(a)+cos(a)
I could then do:
19 matches
Mail list logo
