Proposal for new minor syntax

[Ian Kelly]

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.

Do you mean that this would not be legal?

hello .= strip().upper().encode('utf-8')

Is there a reason you want to disallow that?

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

I realize this is just an example, but does anybody actually use
linked lists in Python outside of class assignments? It seems hard to
justify performance-wise since list is written in C, and if you need
to beat it, then you probably shouldn't be doing so in Python.

> Does this idea have any chance of acceptance if submitted as a PEP? What are
> the potential concerns I could consider with the syntax?

On the plus side it doesn't add any new keywords or conflict with any
existing syntax.

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.