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

[Boris Borcic]

Hello,

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 !!!

<thought_processes>

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.

</though_processes>

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 
issue.

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).

Cheers,

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