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

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

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

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

More information about the Python-Dev mailing list