[Python-ideas] Inline assignments using "given" clauses

[Matt Arcidy]

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
>> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180504/3db63dcb/attachment.html>