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

[Chris Angelico]

On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> All of these are things that a linter should probably catch and warn
> about. If you had said that the break syntax suggestion was a good
> idea but probably better suited as a linter warning than as a
> SyntaxError integrated into the parser, then I would likely agree with
> you. That's not what you said, though. You said the suggestion was
> "ridiculous".

Someone did mention linters at one point, and if I didn't explicitly
agree, I certainly didn't disagree. Let me make my position clearer:

The suggestion that these should be hard errors in the parser is
ridiculous because it is not the parser's job to catch all bugs.
Python is not intended to be that sort of language. It is the job of a
linter to detect probable errors.

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

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

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.

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

So, no, this is not the same.

ChrisA