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 module
import *
For example if I write:
def f(a):
return sin(a)+cos(a)
I could
On Wed, Feb 1, 2012 at 9:11 AM, Olive di...@bigfoot.com 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 module
import *
For
On Feb 1, 11:11 am, Olive di...@bigfoot.com 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__']
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 module
import *
For example if I write:
def f(a):
return
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 frommodule
import *
For example if I write:
def f(a):
On Wed, Feb 1, 2012 at 9:11 AM, Olive di...@bigfoot.com 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 module
import *
For
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 and the
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 bit surprised
On Wed, Feb 1, 2012 at 11:47 AM, Mel Wilson mwil...@the-wire.com 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)
On Wed, Feb 1, 2012 at 3:24 PM, Ethan Furman et...@stoneleaf.us 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
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:53 PM, Ethan Furman et...@stoneleaf.us 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
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
Ian Kelly wrote:
On Wed, Feb 1, 2012 at 3:24 PM, Ethan Furman et...@stoneleaf.us 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,
On Wed, Feb 1, 2012 at 4:41 PM, Ethan Furman et...@stoneleaf.us 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 4:41 PM, Ethan Furman et...@stoneleaf.us 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:
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):
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* know
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
19 matches
Mail list logo
