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" _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com