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

[Tim Peters]

[Tim]
>> ...
>> 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.

[Guido]
> 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.

See my "that deserves more thought" at the start, but wrt future cases
then ;-)  In 3.5 and 3.6, "everything just works" for everyone.  In
3.7 the implementation gets churned again, to go out of its way to
break the handful of code using "async" as an identifier.  It's
obvious who that hurts, but who does that really benefit?

My experience with Fortran convinces me nobody would _actually_ be
confused even if they wrote code like:

async def frobnicate(async=True):
    if async:
        async with ...

But nobody would actually do that.  Then again, "but people _could_ do
that!" barely registers with me because the nobody-actually-does-it
theoretical possibilities were so much worse in Fortran, so I tend to
tune that kind of argument out reflexively.  For example, whitespace
was also irrelevant in Fortran, and these two statements mean
radically different things:

    D O1 0I=1 00,30 0
    D O1 0I=1 00.30 0

The first is like:

    for I in range(100, 301):
        # the block ends at the next statement with label 10

The seconds is like:

    DO10I = 100.300

All actual Fortran code spells them like this instead:

    DO 10 I = 100, 300
    DO10I = 100.300

The differing intents are obvious at a glance then - although, yup, to
the compiler the difference is solely due to that one uses a comma
where the other a period.  I'm not suggesting Python go anywhere near
_that_ far ;-)  Just as far as considering that there's no actual harm
in Fortran allowing "DO" to be a variable name too.  Nobody is even
tempted to think that "DO" might mean "DO loop" in, e.g.,

    DO = 4
    X = FUNC(DO)
    X = DO(Y)
    IF (DO.OR.DONTDO) GOTO 10

etc.  People generally _don't_ use Fortran keywords as identifiers
despite that they can, but it's a real boon for the relatively rare
older code that failed to anticipate keywords added after it was
written.

> ...
> 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.

I've noted before that people don't seem to have trouble finding the
meaning of Python's "is", "and", and "or" either.  But Googling for
"is" (etc) on its own isn't the way to do it ;-)


> 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

Ya - most arguments are crap ;-)