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.
--
https://mail.python.org/mailman/listinfo/python-list
