replacing `else` with `then` in `for` and `try`

[Chris Angelico]

On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
> On 2017-11-03, Steve D'Aprano <steve+python at pearwood.info> wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely not be a syntax error. There's no reason for it
>> to be a syntax error, except to satisfy some arrogant and foolish
>> idea of purity.
>
> It'd be nice if you could be a little less rude. It's not an "arrogant
> and foolish idea of purity", it's to help people catch bugs in their
> code, and to aid their understanding of the language.

That wasn't rudeness. That was an accurate description of the
situation. It is entirely possible for code to be opinionated,
arrogant, foolish, and all those other adjectives that we normally
appropriate to people.

I don't think it would do much for comprehension. And if it's to catch
bugs, that is NOT the job of syntax - it's the job of linters. By all
means, have a linter that says "else clause after loop with no break";
but don't make it *illegal*.

>> There are uncountable ways of writing code which is seemingly
>> "pointless", and we don't make it a syntax error.
>
> And there's uncountable ways of writing code which we *do* make a
> syntax error. I'm not sure what your point is there.

The point is that syntax errors are for things that cannot possibly
make sense, not for things that are likely to be bugs.

There are a very few exceptions, and they're usually things that are
massive bug magnets, or where the semantics are subtly different. And
I can't think of any examples right now other than the way "async def"
forces a function to be a coroutine even if it has no "await"s in it;
note that it does *not* make a syntax error, it simply causes the
semantics to be correct anyway.

>>> No, 'then' describes the opposite of what it does. The word 'then'
>>> implies something that always happens next,
>>
>> Right, which is what happens with the for...else block.
>
> No. Ok, so look. It's obvious that you and I have different mental
> models of the situation here. You're thinking of 'for...else' as two
> arbitrary clauses that run consecutively unless the whole thing is
> aborted by a 'break', whereas I'm thinking of the 'for' clause as
> being a search for a situation that matches a condition and the
> 'else' clause being what happens if the condition is not matched
> (i.e. exactly the same as 'if...else').
>
> Now there's nothing inherently *wrong* with your choice of mental
> model, except it's leading you into confusion because my model means
> the meaning of the 'else' keyword is intuitive and obvious, and yours
> means it's counter-intuitive and confusing. Your suggestion is that
> the fix is to change the language, my suggestion is to fix your model.
> I'd suggest that changing your mind is easier than changing the
> language ;-)

If anything, I would say that Steven's model is at a lower abstraction
layer than yours - though IMO your model is more of an example
use-case than a description of what is actually happening.

>>> Yes, I saw that. It's possible you are the only person in the world
>>> ever to have done that. It would not make the interactive interpreter
>>> 'worse' in the slightest for that silly trick to be lost.
>>
>> Just because you personally haven't used this technique doesn't make it
>> a "silly trick".
>
> It's an incredibly obscure work-around for a different problem,
> i.e. an infelicity in the way the interactive prompt parses input
> blocks. If the parsing is a genuine issue then the answer is to
> fix that, not to look for hacks that almost never help anyway.

TBH I prefer the "if 1:" trick to gather code into a block. But that
requires pre-planning, whereas slapping an "else:" after the loop can
be done after the event.

ChrisA