词汇范围问题 [英] Problem with Lexical Scope
问题描述
我并不完全知道在
Python中词法作用域的状态,但我的理解是这在很长一段时间内已经添加了很多时间
在python2之前。 1-python2.2
我正在使用python2.4并且以下代码抛出了一个状态变量
在最里面的函数中找不到即使我试图全球化它。
def收集(字段,减速器):
def规则(记录):
status = True >
def _(x,y):
cstat = reducer(x,y)
如果状态而不是cstat:
status = False
返回y
返回减少(_,[字段中字段的记录[字段]])
返回规则
是什么给出的?
好吧,我觉得我找到了一个讨厌的小黑客来获取在它周围,但我还是
不知道为什么它不能正常工作。
def collect(字段,减速机) :
def规则(记录):
#讨厌黑客b / c无法获得工作状态的词汇范围
status = [True]
def _(x,y,s = status):
cstat = reducer(x,y)
if s [ 0]而不是cstat:
s [0] = False
返回y
减少(_,[字段中的字段的记录[字段] ])
返回状态[0]
返回规则
js ****** @ gmail。 com 写道:我对Python中词法作用域的状态并不完全了解,但据我所知,这是在很长一段时间内添加的
前面围绕python2.1-python2.2
我正在使用python2.4并且下面的代码抛出一个状态变量
在最里面的函数中找不到,即使我在试着全球化它收集(字段,缩减器):
def规则(记录):
status = True
def _(x,y):
cstat = reducer(x,y)
如果状态而不是cstat:
status = False
return y
return reduce(_,[field [field] for field in fields ])
返回规则
什么给出?
当翻译器编译内部时,发生了什么?
函数_(),看到状态的赋值,因此假设它是本地的_(b)_()函数。因此,由于你在
赋值之前在_()中引用它,你得到(我推测)报告未绑定的本地
变量的异常。
当您遵守规则时,范围规则会起作用:
def f1(a,b):
... s = a + b
... def _(x):
...返回s + x
...返回_
... func = f1(12,13)
func(10)
35
这里嵌套的词法范围规则并没有那么有用,因为
覆盖内部范围内的赋值性质。使用全局意志
只需将状态变量放在* module *范围内,这也不是什么
你想要的。
问候
Steve
-
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 < a rel =nofollowhref =http://www.python.org/pycon/\"target =_ blank> www.python.org/pycon/
这确实有意义。那么有没有办法修改
外部词法范围内的变量?是否使用可变数据类型是唯一的方法?
我试图想到一个案例会在
能够产生语义模糊时修改外部作用域中的变量引用,但是我没有b $ b不能(这可能是短视的)。这种行为是否正确
因为性能还是因为某种设计的
翻译?
I am not completely knowledgable about the status of lexical scoping in
Python, but it was my understanding that this was added in a long time
ago around python2.1-python2.2
I am using python2.4 and the following code throws a "status variable"
not found in the inner-most function, even when I try to "global" it.
def collect(fields, reducer):
def rule(record):
status = True
def _(x, y):
cstat = reducer(x, y)
if status and not cstat:
status = False
return y
return reduce(_, [record[field] for field in fields])
return rule
What gives?
Well, I think I found a nasty little hack to get around it, but I still
don''t see why it doesn''t work in the regular way.
def collect(fields, reducer):
def rule(record):
# Nasty hack b/c can''t get lexical scoping of status to work
status = [True]
def _(x, y, s=status):
cstat = reducer(x, y)
if s[0] and not cstat:
s[0] = False
return y
reduce(_, [record[field] for field in fields])
return status[0]
return rule
js******@gmail.com wrote:I am not completely knowledgable about the status of lexical scoping in
Python, but it was my understanding that this was added in a long time
ago around python2.1-python2.2
I am using python2.4 and the following code throws a "status variable"
not found in the inner-most function, even when I try to "global" it.
def collect(fields, reducer):
def rule(record):
status = True
def _(x, y):
cstat = reducer(x, y)
if status and not cstat:
status = False
return y
return reduce(_, [record[field] for field in fields])
return rule
What gives?
What''s happening is that the interpreter, when it compiles the inner
function _(), sees an assignment to status and so assumes it is local to
the _() function. Consequently, since you reference it inside _() before
assignment you get (I presume) an exception reporting an unbound local
variable.
The scoping rules do work when you obey them:
def f1(a, b): ... s = a+b
... def _(x):
... return s+x
... return _
... func = f1(12, 13)
func(10) 35
Here the nested lexical scopes rule isn''t that helpful given the
overriding nature of assignment within an inner scope. Using global will
simply put the status variable at *module* scope, which also isn''t what
you want.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
That does make sense. So there is no way to modify a variable in an
outer lexical scope? Is the use of a mutable data type the only way?
I''m trying to think of a case that would create semantic ambiguity when
being able to modify a variable reference in an outer scope, but I
cannot (which is probably short-sighted). Is this behavior correct
because of performance or perhaps because of a certain design of the
interpreter?
这篇关于词汇范围问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!