Proposal for new minor syntax

[BartC]

On 27/03/2015 20:48, Ian Kelly wrote:
> On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
> <jw14896.2014 at my.bristol.ac.uk> wrote:
>> I would like to propose a new piece of syntax for the python language; .=
>>
>> In short, the operator is form of syntactic sugar, for instance consider the
>> following code:
>>
>> hello = "hello world              "
>> hello = hello.strip()
>>
>> This could be written as:
>>
>> hello = "hello world              "
>> hello .= strip()
>>
>> In this slightly contrived example, the programmer saved (a small amount of)
>> time when writing the code. With code with longer variable names, or lots of
>> similar statements all in a row, this helps to keep code more concise.
>>
>> The operator would be constricted to one method or field on the right-hand
>> side, which must belong to the object on the left hand side.

>> Another example could be when using Linked Lists, instead of writing
>> something like:
>>
>> loop_node = loop_node.next
>>
>> you could write:
>>
>> loop_node .= next

An alternate syntax might be:

  hello = .string()
  loop_node =. next

With flexible white space either side of "." unless it is important that 
".=" or "=." is a single token.

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.

-- 
Bartc