On Fri, May 4, 2018, 11:35 Guido van Rossum
On Fri, May 4, 2018 at 11:11 AM, Tim Peters
wrote: [Nick Coghlan
] ... Using a new keyword (rather than a symbol) would make the new construct easier to identify and search for, but also comes with all the downsides of introducing a new keyword.
That deserves more thought. I started my paying career working on a Fortran compiler, a language which, by design, had no reserved words (although plenty of keywords). The language itself (and vendor-specific extensions) never had to suffer "but adding a new keyword could break old code!" consequences.
In practice that worked out very well, Yes, you _could_ write hard-to-read code using language keywords as, e.g., identifier names too, but, no, absolutely nobody did that outside of "stupid Fortran tricks" posts on Usenet ;-) It had the _intended_ effect in practice: no breakage of old code just because the language grew new constructs.
It's no longer the case that Python avoided that entirely, since "async def", "async for", and "async with" statements were added _without_ making "async" a new reserved word. It may require pain in the parser, but it's often doable anyway. At this stage in Python's life, adding new _reserved_ words "should be" an extremely high bar - but adding new non-reserved keywords (like "async") should be a much lower bar.
Do note that this was a temporary solution. In 3.5 we introduced this hack. In 3.6, other uses of `async` and `await` became deprecated (though you'd have to use `python -Wall` to get a warning). In 3.7, it's a syntax error.
That said, I expect it's easier in general to add a non-reserved keyword introducing a statement (like "async") than one buried inside expressions ("given").
I'd also say that the difficulty of Googling for the meaning of ":=" shouldn't be exaggerated. Currently you can search for "python operators" and get tons of sites that list all operators.
Without adding hits to the search algorithm, this will remain the case. Google must have clicks to rank up. Right now there is no page, nothing on a high "Google juice" page like python.org, no one searching for it, and no mass of people clicking on it. no SO questions, etc. there is a transient response for all change. uniqueness and length of search term is just a faster one. All python syntax is findable eventually due to popularity. plus a better search is "why would I use...in python" or similar. = python also doesn't bring up anything interesting that wouldn't be had because of just "python". The details are too mundane and/or technical and everyone knows already.
that being said, if := had been (theoretically) included from the beginning, would people continue to have issues with it? unlikely, but I can't know. familiarity will cure many of these issues of readability or symbolic disagreement no matter what is chosen (well, to a point). it's unfortunate that changes have to be made up front with so little information like that, so I'm not advocating anything based on this, just pointing it out. I do think post hoc assignment will cause a cognitive load, like trying to figure out which variable is the iterator, and having to keep two contexts till the end of a comp with one given statement. [f(x) + a for all a in blah given x=1] not worse than a double nested comp though.
I also note that Google seems to be getting smarter about non-alphabetic searches -- I just searched for "python << operator" and the first hit was https://wiki.python.org/moin/BitwiseOperators
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/