On 2017-12-23 04:01, Peng Yu wrote:
Hi, The following example shows that both locals() and globals() are
updated when x and f are defined. Shouldn't they be considered and
global variable and functions only? Why does it make sense to set
locals() as well? Thanks.
It's "local&quo
On Sat, 23 Dec 2017 03:01 pm, Peng Yu wrote:
> Hi, The following example shows that both locals() and globals() are
> updated when x and f are defined. Shouldn't they be considered and
> global variable and functions only? Why does it make sense to set
> locals() as well? Thanks.
Hi, The following example shows that both locals() and globals() are
updated when x and f are defined. Shouldn't they be considered and
global variable and functions only? Why does it make sense to set
locals() as well? Thanks.
$ cat ./main.py
#!/usr/bin/env python
# vim: set noexpandtab ta
Paolo Pantaleo wrote:
> Hi
>
> this exaple:
>
> def lcl():
> n=1
> x=locals()
> x["n"]=100
> print "n in lcl() is:" +str(n)
> #This will say Name error
> #x["new"]=1
> #print new
>
>
> n=1
> x=globals()
> x["n"]=100
> print "gobal n is:" +str(n)
> x["new"]=1
> print "new
Paolo Pantaleo wrote:
> why accessing the names dictionary globals() and locals() gives
> different results?
the documentation has the answer:
"The contents of this dictionary should not be modified;
changes may not affect the values of local variables used
by the interpreter"
http:
Hi
this exaple:
def lcl():
n=1
x=locals()
x["n"]=100
print "n in lcl() is:" +str(n)
#This will say Name error
#x["new"]=1
#print new
n=1
x=globals()
x["n"]=100
print "gobal n is:" +str(n)
x["new"]=1
print "new is:" +str(new)
lcl()
produces
gobal n is:100
new is:1
n
On Wed, 8 Dec 2004 20:22:52 -0500, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>To respond to and summarize several posts in this discussion:
>
>Within a function, where the local namespace is distinct from the global
>(module) namespace, CPython usually implements the local namespace
>internally a
Jeff Shannon wrote:
Steven Bethard wrote:
Jeff Shannon wrote:
Note also that functions which use exec cannot use the static
namespace optimization, and thus tend to be *much* slower than normal
functions
In what circumstances will this be true? I couldn't verify it:
[snip]
I was referring to fu
To respond to and summarize several posts in this discussion:
Within a function, where the local namespace is distinct from the global
(module) namespace, CPython usually implements the local namespace
internally as a fixed-length array. When this is true, locals() is a
*copy* of the local nam
Steven Bethard wrote:
Jeff Shannon wrote:
Note also that functions which use exec cannot use the static
namespace optimization, and thus tend to be *much* slower than normal
functions
In what circumstances will this be true? I couldn't verify it:
[...]
exec """\
def fib2(n):
a, b = 0, 1
Jeff Shannon wrote:
Note also that functions which use exec cannot use the static namespace
optimization, and thus tend to be *much* slower than normal functions
In what circumstances will this be true? I couldn't verify it:
> cat fib.py
def fib1(n):
a, b = 0, 1
while True:
a, b
Jeff Shannon wrote:
(Note also that functions which use exec cannot use the static namespace
optimization, and thus tend to be *much* slower than normal functions
(in addition to being a huge security problem). I don't know, however,
whether locals() can update the local namespace in such un-op
Steven Bethard wrote:
I remember hearing an explanation of why locals() is not writable that
had to do with something about efficiency and the call stack (or
something like that)...
IIRC, the function local namespace (in CPython) is kept internally as a
static array, rather than as a dictionary
t updated. locals() is readable but not
writable in any case where locals() is not globals(), I believe.
But "unreliable" sounds kinda vague and intermittent, and I assume that
is not the case here - What is the Rule(tm)?
Unfortunately, I don't think there is a Rule(tm) because t
- What is the Rule(tm)?
Thanks
Caleb
On Wed, 08 Dec 2004 16:59:23 GMT, Steven Bethard
<[EMAIL PROTECTED]> wrote:
Peter Hansen wrote:
Nick Coghlan wrote:
Generally, altering the contents of the dicts returned by locals() and
globals() is unreliable at best.
Nick, could you please comme
Peter Hansen wrote:
Nick Coghlan wrote:
Generally, altering the contents of the dicts returned by locals() and
globals() is unreliable at best.
Nick, could you please comment on why you say this about globals()?
I've never heard of any possibility of "unreliability" in updating
gl
16 matches
Mail list logo
