A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-May/111300.html below:

[Python-Dev] more timely detection of unbound locals

[Python-Dev] more timely detection of unbound locals [Python-Dev] more timely detection of unbound localsSteven D'Aprano steve at pearwood.info
Mon May 9 18:39:14 CEST 2011
Eli Bendersky wrote:
>> I think you are making an unwarranted assumption about what is "more
>> expected". I presume you are thinking that the expected behaviour is that
>> foo() should:
>>
>> print global x (5)
>> assign 1 to local x
>> print local x (1)
>>
>> If we implemented this change, there would be no more questions about
>> UnboundLocalError, but instead there would be lots of questions like "why is
>> it that globals revert to their old value after I change them in a
>> function?".
>>
> 
> True, but this is less confusing and follows the rules in a more
> straightforward way. x = 1 without a 'global x' assigns a local x, this make
> sense and is similar to what happens in C where an inner declaration
> temporarily shadows a global one.

I disagree that it is less confusing. Instead of a nice, straightforward 
error that you can google, the function will silently do the wrong 
thing, giving no clue that weirdness is happening.

def spam():
     if x < 0:  # refers to global x
         x = 1  # now local
     if x > 0:  # could be either global or local
         x = x - 1  # local on the LHS of the equal
         # sometimes global on the RHS
     else:
         x += 1  # local x, but what value does it have?


Just thinking about debugging the mess that this could make gives me a 
headache.



-- 
Steven

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4