[Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

[Steven D'Aprano]

On Thu, Nov 17, 2016 at 07:37:36AM +0100, Mikhail V wrote:
> On 17 November 2016 at 01:06, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> > It doesn't matter what keyword you come up with, you still have the
> > problem that this idea introduces a new keyword. New keywords always
> > break backwards compatibility, which means there has to be a good reason
> > to do it.
> > Any meaningful name you pick as a keyword will probably clash with
> > somebody's code, which means you will break their working program by
> > introducing a new keyword.
> 
> I appreciate how you explain things, you point to the root of problems and
> it always makes my logic better.

Thank you :-)


[...]
> > But the first question
> > we'd ask is, what do other languages do? Python rarely invents new
> > programming ideas itself, but it does copy good ideas from other
> > languages.
> 
> I don't know why, but this sounds somehow pessimistic.

In some ways it is. But Python is a conservative language (despite the 
"radical" feature of significant indentation, but even that was a proven 
concept from at least one other language, ABC, before Guido used the 
idea). Things may have been different two decades ago when Python was a 
brand-new language with a handful of users. Python is a mature language 
now with a huge user-base. It is probably one of the top five most 
popular languages in the world, and certainly one of the top ten.

We have a responsibility to our users:

- to minimise the amount of disruption to their code when they upgrade;

- that means avoiding breaking backwards compatibility unless there is 
  significant benefit to make up for the pain;

- and long deprecation periods before removing obsolete features;

- since it typically takes five years, or even ten, to remove a 
  deprecated feature, we should avoid wasting users' time by adding new 
  and exciting experimental features that turn out to be a bad idea.

Nick Coghlan has a good blog post that explains the tension in the 
Python community between those who want the language to evolve faster, 
and those who want it to evolve slower:

http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html

For people used to the rapid change in the application space (new 
versions of Chrome virtually daily; Ubuntu brings out new operating 
system versions every six months) Python seems to move really, really 
slowly. But for a programming language, Python moves radically fast: 
most C code written in the 1970s probably works correctly today, and it 
can easily be a decade between C versions.


[...]
> First main question then would be:
> Are augmented assignment operators needed *much*?

They are. They were one of the most often requested features before 
Python. Most people consider that they improve the quality of code.


[...]
> In this case the work on thinking out a better
> syntax for in-place stuff is not so useless as it
> seems to be now.

Mikhail, you are missing the point that people have already spent 
decades thinking about "a better syntax for in-place stuff", and for 
Python that syntax is augmented assignment.

I'm sorry that *you personally* don't like this syntax. That puts you in 
a very small minority. Not everybody likes every part of Python syntax. 
But I think it is time for you to give up: you cannot win this battle.


> If Python will *someday* be able to optimise
> the simple A = A + 1 to in-place without
> need of special syntax (by type annotation probably?),

I really, really hope not.

Type annotations are irrelevant here. Python doesn't need type 
annotations to know the type of A at runtime.

The advantage of augmented assignment is that it allows me, the 
programmer, to decide whether or not I want in-place array operations. 
It is *my* choice, not the compiler's, whether I create a new list:

    A = B = [1, 2, 3]
    A = A + [4]
    assert B == [1, 2, 3]

or make the change in-place:

    A = B = [1, 2, 3]
    A += [4]
    assert B == [1, 2, 3, 4]


[...]
> WAS:
> Binary_mask += numpy.sum(B, C)
> 
> NEW:
> 1). prefix keyword approach examples:
> 
> incal  Binary_mask + numpy.sum(B, C)
> inc    Binary_mask + numpy.sum(B, C)
> calc   Binary_mask + numpy.sum(B, C)
> exec   Binary_mask + numpy.sum(B, C)

Those suggestions waste perfectly good and useful variable names as 
keywords (I have code that uses inc and calc as names, and exec is the 
name of a built-in function). And not one of those examples makes it 
clear that this is an assignment.

Augmented assignment does make it clear: it uses a variation on the = 
binding operator. (Its not actually an operator, but for lack of a 
better name, I'll call it one.) It follows the same basic syntax as 
regular assignment:

    target = expression

except that he augmented operator is inserted before the equals sign:

    target -= expression
    target += expression
    target *= expression

etc.

At this point, I think it is a waste of time to continue discussing 
alternatives to augmented assignment syntax. I'm happy to discuss the 
culture of Python and how we decide on making changes to the language, 
but I am not interested in discussing augmented assignment itself.



-- 
Steve