[Python-ideas] Inline assignments using "given" clauses
marcidy at gmail.com
Fri May 4 15:27:28 EDT 2018
On Fri, May 4, 2018, 11:35 Guido van Rossum <guido at python.org> wrote:
> On Fri, May 4, 2018 at 11:11 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> [Nick Coghlan <ncoghlan at 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
>> 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
>> 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"
= 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
> --Guido van Rossum (python.org/~guido)
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas