for / while else doesn't make sense

[Erik]

On 21/05/16 11:39, Steven D'Aprano wrote:
> Just for the record, that's not my mental model *now*.

Sure. And I should have written "one's mental model" - the model of 
anyone writing that code (not you personally) who thought the same at 
the time.

> It took me a long time to work out what for...else was actually doing, but
> some years ago I finally managed to do so.

Coming from a partly assembler background, I happened to get it straight 
away just because the thought of separate jump targets for the loop 
condition being satisfied and breaking out of the loop being different 
was quite natural (and a very nice feature to have in a high level 
language!).

> But you do ask a good question. Why isn't for...else with no break a syntax
> error? I suppose it could be. But that's a *stylistic* question, and Python
> generally treats that as "none of the compiler's business". It's not the
> business of the compiler to enforce good code, only legal code.

On 21/05/16 08:29, Chris Angelico wrote:
 > It's up to the linter, and ONLY the linter, to tell you about this.

Apologies for joining two threads here, but my reply is the same to 
both, so it makes sense to me.


Let me tell you a story ;) <wibbly-wobbly-lines> Back in the mid-to-late 
1980s I worked with C compilers on hardware that could take several 
minutes to compile even a fairly trivial program. They errored on 
syntactically incorrect code and happily compiled syntactically correct 
code. Sometimes the output of the compiler wouldn't execute as expected 
because of "undefined behaviour" of some parts of the language (which 
the compilers could quite legally accept but would not produce valid 
code for - even illegal ops are fair game at that point). They would 
create valid code for the valid syntax of buggy code ("if (x = y) { 
foo(); }") without a whimper.

At that time, we had a program called 'lint'. Every so often we might 
run it on our sources and find all sorts of questionable behaviour that 
our code might have that we should look harder at (such as that above). 
We didn't run it all the time because it took so much longer to run than 
the compiler itself.

Over time, some compilers started adding the checks and advisories that 
"lint" gave to their messages. For some branded compilers ("Green 
Hills", "SAS/C"), this even became a selling point. They started to do 
this while still retaining the original compilation speed.

Things got faster, more was added to the compiler, and once the compiler 
started to do everything it did and more, lint died(*).

</wibbly-wobbly-lines>

And now, today, the compilers all do far more than the original 'lint' 
program did in almost zero time every time some source is compiled. It 
is free; it is not something one has to remember to run every so often.




So, back to Python ;)

The responses of "we can all write suspect/bad/ineffectual code - so 
just run the linter" takes me back those 30 years to when we HAD to do 
that with our C code too ...

There must be a better way.

I realise that Python has the issue that sometimes the person doing the 
compilation is the end user (by virtue of them executing a .py file), so 
lint-style compiler warnings aren't really appropriate - and that's the 
reason why I suggested a syntax error: I understand that it's not really 
any such thing, but it's all I had to work with and it ensured such code 
could not get as far as the end user.


So I guess my question is perhaps whether Python compilers should start 
to go down the same path that C compilers did 30 years ago (by starting 
to include some linter functionality) but in a way that only outputs the 
messages to developers and not end users. Also, the current "pylint" 
blurs the edges between style (identifier names) and questionable code 
("for/else" with no "break").



E. <-- waiting to be shot down again.



(*) Though to be fair, there are now even more deeply checking 
(commercial) static tools available, which effectively fill the gap that 
'lint' used to.