Proposal for new minor syntax

[Steven D'Aprano]

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