[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
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"
More information about the Python-Dev
mailing list