On Thu, Nov 17, 2016 at 07:37:36AM +0100, Mikhail V wrote:
On 17 November 2016 at 01:06, Steven D'Aprano email@example.com 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:
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 +  assert B == [1, 2, 3]
or make the change in-place:
A = B = [1, 2, 3] A +=  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
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.