Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Ian Kelly]

On Tue, Nov 7, 2017 at 2:42 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> Not one of these is syntactically invalid. Why should "else without
>>> break" be trapped by the parser? Your other examples mostly have good
>>> parser-level reasons for being errors
>>
>> No, they don't. All four of them could just as easily also be accepted
>> by the parser and only flagged as linter warnings.
>
> If everyone in the world agreed that a tab was equal to eight spaces,
> then I would agree that the tab/space discrepancy could be considered
> a linter warning. But there's no such agreement, which means that
> having the language declare some equivalency is extremely dangerous.

Really? I've never actually heard a story of anybody being bitten by
this. I'm not disputing that it was a useful change, but I think
"extremely dangerous" is an exaggeration.

> Py2 had several language features and misfeatures that are that
> dangerous (having the simple name "input()" do evaluation is a trap
> that MANY people have fallen into), and it's correct to fix that. If
> Python had, from the start, treated tabs and spaces as different forms
> of indentation, there would be no reason to change that now.

There were also plenty of backward-incompatible changes in Py3 that
had nothing to do with dangerous code.

> Whether True and False are keywords or builtins is a matter of debate,
> but there are definite advantages to them being locked down, and the
> only real disadvantage that I see is the question of consistency (eg
> "Ellipsis" is not a keyword, so you can still assign to that).

The other disadvantages are: making the change was
backward-incompatible, and it prevents the user from overriding their
values, which might sometimes be useful in the same way that
overriding print might sometimes be useful -- which was one of the
reasons for demoting print from keyword status!

> Having star imports be bypassed when looking for nonlocals is going to
> be extremely confusing if you DO import a name from the other module.
> There's no right answer to the nonlocal lookup question, so the best
> thing to do is to not permit it. There's fundamentally no way for this
> to be both legal and sane in all situations, so it can't be left up to
> the linter.

I disagree. Always using the variable that is explicitly assigned
would be both legal and sane in all situations. It also allows an easy
fix: just explicitly assign the variable in the scope where you
actually want it. Yes, some people might be confused when their star
import isn't picked up by nonlocal, but people also get confused by
late binding of nonlocals, or the behavior of mutable default values,
or the distinction between modifying a list and reassigning it, etc.
etc. Nobody is suggesting that defining a closure inside a loop ought
to be a SyntaxError, but it is probably something that linters should
be looking for, if they don't already.

> Mixing 'async def' and 'yield from' is, AIUI, more of a
> NotImplementedError than a SyntaxError; the wording of the PEP
> basically says that it's low priority, not that it's a bad thing. So
> that one is never going to be flagged by a linter - once it's made
> possible, it'll be the normal and expected behaviour, so there's no
> reason to flag it (except perhaps as "beware that this is not backward
> compatible with Python <3.8").

I was not referring to the possible future use of yield from for async
generators; I was referring to the possibility *today* of using "yield
from" as a synonym for *await*. As far as I know the only major
obstacle to that is that the authors (with good reason) made it a
SyntaxError. This is exactly the same sort of situation: it's a
construct that would otherwise be perfectly valid, but it's made a
SyntaxError specifically to prevent users from doing some the devs
don't want them to.