On Fri, May 4, 2018, 11:35 Guido van Rossum <gu...@python.org> wrote:
> On Fri, May 4, 2018 at 11:11 AM, Tim Peters <tim.pet...@gmail.com> wrote: > >> [Nick Coghlan <ncogh...@gmail.com>] >> > ... >> > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/