On Monday 27 October 2003 04:11 pm, Guido van Rossum wrote: ...
I don't think you'll ever *have* to explain this anyway, as long as := and += use the same rules to find their target (I'd even accept
Actually, I'd like to make a := ... an error when there's an a = ... in the same function, so it can't be exactly the same rules for a += ... in my opinion.
I'm *not* saying that I like := (so far I still like 'global x in f'
Ah well.
I think the main weakness (for me) of := and other approaches that try to force you to say you're rebinding a nonlocal each time you do it is beginning to show: there are already well-established rules for deciding whether a bare name is local or not, and those rules have
There are, but they represent a wart (according to AMK's python-warts page, http://www.amk.ca/python/writing/warts.html , and I agree with him on this, although NOT with his suggested fix of having the compiler "automatically adding a global when needed" -- I don't like too-clever compilers that make subtle inferences behind my back, and I think that the fact that Python's compiler doesn't is a strength, not a weakness). The "well-established rules" also cause one of the "10 Python pitfalls" listed at http://zephyrfalcon.org/labs/python_pitfalls.html . My personal experience teaching/consulting/mentoring confirms this, although I, personally, don't remember having been bitten by this (but then, I recall only 2 of those 10 pitfalls as giving trouble to me personally, as opposed to people I taught/advised/etc: mutable default arguments, and "loops of x=x+y" performance traps for sequences). It seemed to me that introducing := (or other approaches that require explicit denotation of "I'm binding a nonlocal here") was a chance to FIX the warts/pitfalls of those "already well-established rules". Albeit with a heavy heart, I would consider even a Rubyesque stropping of nonlocals (Ruby uses $foo to mean foo is nonlocal, others here have suggested :foo, whatever, it's not the sugar that matters most to me here) preferable to using "declarative statements" for the purpose. Oh well.
always worked "at a distance". The main reason for disallowing rebinding nonlocals in the past has been that one of those rules was "if there's a bare-name assignment to it it must be local (unless there's also a global statement for it)" (and I couldn't find a satisfactory way to add a nonlocal declarative statement and I didn't think it was a huge miss -- actually I still think it's not a *huge* miss).
Agreed, not huge, just probably marginally worth doing. Should it make "declarative statements" more popular and widely used than today's bare "global", I don't even know if it would be worth it. I don't like declarative statements. I don't understand why you like them here, when, in your message of Thursday 23 October 2003 06:25:49 on "accumulator display syntax", you condemned a proposal "because it feels very strongly like a directive to the compiler". "A directive to the compiler" is exactly how "global" and other proposed declarative-statements feel to me: statements that don't DO things (like all other statements do), but strictly and only are "like a directive to the compiler".
and it doesn't seem to me that the two extra keystrokes are to be considered a substantial price to pay.
That's the argument that has always been used against += by people who don't like it. The counterargument is that (a) the savings in typing isn't always that small, and (b) += *expresses the programmer's
The saving in typing is not always small _when on the left of the augmented assignment operator you have something much more complicated than just a bare name_. For example, counter[current_row + current_column * delta] += current_value Without += this statement would be too long, and it would be hard to check that the LHS and RHS match exactly -- in practice one would end up breaking it in two, current_index = current_row + current_column * delta counter[current_index] = counter[current_index] + current_value which IS still substantially more cumbersome than the previous version using += . But this counterargument does not apply to uses of += on bare names: the saving is strictly limited to the length of the bare name, which should be reasonably small.
thought better*. Personally I expect that as soon as nonlocal rebinding is supported in any way, people would be hugely surprised if += and friends were not.
We could try an opinion poll, but it's probably worth it only if this measure of "expected surprise" was the key point for your decision; if you're going to prefer declarative statements anyway, there's no point going through the aggravation.
If we do rely on augmented assignment being "rebinding":
def accumulator_saturating(n=0, m=100): def increment(i): if n > m: n = i else: n += i return n return increment
the error becomes a runtime rather than compile-time one, and does take a (small but non-zero) time to discover it.
Hah. Another argument *against* rebinding by :=, and *for* a nonlocal declaration. With 'nonlocal n, m' in increment() (or however it's spelled :-) the intent is clear.
I disagree that the example is "an argument for declarations": on the contrary, it's an argument for := without "rebinding +=". The erroneous example just reposted gives a runtime error anyway (I don't know why I wrote it would give a compile-time error -- just like a bare "def f(): x+=1" doesn't give a compile-time error today, so, presumably, wouldn't this reposted example). If "n := n + i" WAS used in lieu of the augmented assignment, THEN -- and only then -- could we give the preferable compile- time error, for forbidden mixing of "n = ..." and "n := ..." in different spots in the same function. Alex