[Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
bborcic at gmail.com
Mon Jun 12 14:20:48 CEST 2006
Armin Rigo wrote:
> 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
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))
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).
"On naît tous les mètres du même monde"
More information about the Python-Dev