[Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

Boris Borcic bborcic at gmail.com
Mon Jun 12 14:20:48 CEST 2006


Armin Rigo wrote:
> Hi,
> On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
>> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
>> doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles
>> the following code incorrectly:
> No, no, it's an underground move by Jeremy to allow assignment to
> variables of enclosing scopes:
> Credits to Samuele's evil side for the ideas.  His non-evil side doesn't
> agree, and neither does mine, of course :-)
> More seriously, a function with a variable that is only written to as
> the target of augmented assignments cannot possibly be something else
> than a newcomer's mistake: the augmented assignments will always raise
> UnboundLocalError.

I am not really a newcomer to python. But lately I find myself regularly bitten
by this compiler behavior that I tend to view as a (design) bug. This started
happening after I saw that sets are just as good as lists performance-wise and I
began changing code like this

def solve(problem) :
     freebits = [True for _ in range(N)]
     def search(data) :
         for b in swaps :
             freebits[b] ^= 1

to more concise and clearer code like that

def solve(problem) :
     freebits = set(range(N))
     def search(data)
         freebits ^= swaps

At such points, I find it a huge violation of the principle of least surprise 
that the compiler forbids to mean 'x.__ixor__(y)' with 'x ^= y' and interprets 
the latter to mean something different. Given that this preferred meaning is 
certain to cause a misleading runtime error !!!


What ? It *wants* me to write x.__ixor__(y) *spontaneously* ?

I can't believe it ! What's in dir(set) ?

Oh, what's that, set.symmetric_difference_update() !?

Why not set.lets_get_miles_out_of_our_way_to_accomodate_some_evil_theories() ?

Mhh, set.X_update() admits iterables while augmented assignments require other 
sets [a vital difference for sure ;)] so maybe it's just by accident that the 
set API offers a good enough equivalent to x ^= y to escape having to use 
x.__ixor__(y) in similar contexts.


Now reading this thread where somebody files a patch to "rectify" 2.5a2 behaving 
sanely on this issue, and somebody else follows up to -jokingly- argue in favor 
of sanity while confessing to the latter's evilness - that tells me that some 
really weird behind-the-looking-glass official theory might indeed dominate the 

Is that theory written somewhere ? Or is it just the manifestation of a bug in 
the BDFL's famed time machine ? (I am saying this because Guido recently argued 
that sets should integrate as if they had been designed into Python from the 
beginning, what the above flagrantly contradicts imho).


Boris Borcic
"On naît tous les mètres du même monde"

More information about the Python-Dev mailing list