On Thu, Nov 17, 2016 at 07:37:36AM +0100, Mikhail V wrote: > On 17 November 2016 at 01:06, Steven D'Aprano <st...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
