On Sat, 28 Mar 2015 10:08 am, BartC wrote:
> An alternate syntax might be:
>
> hello = .string()
> loop_node =. next
Why propose that?
Every other augmented assignment has the operator on the left hand side of
the equals. Greater-than, less-than, and not-equal all have the symbol on
the left hand side of the equals:
+= -= *= **= /= //= %= |= ^= &= <= >= != =.
All together now, let's sing: "One of these things is not like the other..."
[That song is from Sesame Street, for anyone who doesn't get the reference.]
It doesn't even solve the "grit on Tim's monitor" test, it just moves the
whitespace from one side to the other:
hello .= strip()
hello =. strip()
Moving the dot to the other side just makes it an arbitrary change for
people to get confused by.
> With flexible white space either side of "." unless it is important that
> ".=" or "=." is a single token.
py> x = 2
py> x + = 1
File "<stdin>", line 1
x + = 1
^
SyntaxError: invalid syntax
I think that being able to write:
x + = 1
adds complexity for no benefit. If we don't allow spaces between + = we
shouldn't allow them between . and = in this proposal.
> I'm assuming that an isolated "." is not a valid starter symbol for
> anything else, other than a floating point constant such as hello =.3
>
>> On the minus side it seems marginal in utility to me, as all it does
>> is save a bit of typing. The +=, etc. operators are backed by special
>> methods named __iadd__ etc. which allows the class author to provide
>> for the operation to be performed in-place, or to change the meaning
>> entirely use the operator as part of a DSL. This proposal doesn't have
>> any room that I can see for that sort of benefit.
>
> It needn't require that sort of support. It does just save typing in the
> same way that A += B does, and makes it a little clearer what is being
> expressed. Except that with A = .B, A will be evaluated twice.
It saves typing. It might even allow a micro-optimization in the generated
bytecode (see below). But I don't think it's clearer -- the opposite,
really, I think it's a bit unclear.
You can't be any clearer than the explicit:
greeting = greeting.strip()
This tells you explicitly what's being evaluated on the right hand side, and
explicitly what it's being bound to.
greeting .= strip()
requires you to learn yet another special piece of syntax, after which you
can fill in the implicit attribute lookup:
greeting .= strip() # greeting.strip()
Personally, I'm not a huge fan of augmented assignment += etc. There is no
doubt that it has the advantage of saving typing, but it leads to more
complexity:
(1) `x += y` *is not* semantically equivalent to `x = x + y`
(2) augmented assignment involving tuples can be awkward:
t = ([1, 2, 3], None, "spam")
t[0] += [4]
The problem isn't that the second line raises an exception, but that the
second line raises an exception and yet the addition succeeded.
So I am fairly dubious about extending a mixed blessing like augmented
assignment even further.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
