How coding in Python is bad for you
Erik
python at lucidity.plus.com
Wed Feb 1 18:49:47 EST 2017
On 30/01/17 02:14, Steve D'Aprano wrote:
> On Mon, 30 Jan 2017 10:52 am, Erik wrote:
>> It would be even better if it was "else if not break:" to make the
>> meaning clearer.
>
> break is not the only way to exit the for loop
Fine - "else if not break or raise or return:", then ;) [that is not a
serious suggestion]
You're conflating two types of exit though. One is a way of exiting the
innermost loop construct and nothing more. The others are ways of
exiting a separate, outer construct (be that a try block or a
function/method).
I'm specifically talking about the interaction between 'break' and
'else'. The other things are at a different level.
>> I would agree that it would be even better than that if
>> it was "then if not break:" (apart from needing the new keyword ;)), as
>> then the conditional aspect is explicit.
>
> But it isn't conditional.
Yes it is. When one reads the code, the statements in the "else:" (or
your theoretical "then:") block will be executed only if a "break" was
not executed in the loop statements the "then:" is associated with. How
is that NOT conditional?
> Your syntax implies that the interpreter keeps
> some sort of flag did_we_reach_the_end_of_the_loop_without_break or
> something, and then it checks the state of that flag. There is no such
> flag.
You are correct and I never said there was - you're now arguing against
a point that you have made and I didn't!
I have written more than my fair share of assembly code in the past and
can identify the "for/while" vs "else" construct as a loop with two exit
targets that are jumped to unconditionally. In fact, that was one of the
"oh, nice!" moments when I first learned Python - I'd never seen a high
level language do that before (even C doesn't have it!).
All I have said is that the *spelling* of "else:" could be "else if not
break:" or - because you mentioned it and I think it actually reads
better - "then if not break:".
> They hoped to use the same flag the for-loop used.
Well, _logically_ there is a flag (in as much as it could be thought of
like that to make it easy to understand - and in C, that's pretty much
what you have to actually do unless you really want to use 'goto').
> Not a single condition to be seen, anywhere. Its all unconditional jumps.
>
> To anticipate a possible objection: it is possible that the FOR_ITER
> bytecode is implemented with a conditional test, but even so, all that
> tests for is whether to enter the main body of the for-loop (10
> STORE_NAME ...) or jump to (18 LOAD_NAME ...).
Again, you're arguing against something I didn't say. I never suggested
"if not break" (whether following "else" or "then") should generate code
that dynamically tests some sort of flag. It's just a different way of
spelling exactly the same construct we have today, generating exactly
the same bytecode.
I can see what you're trying to say, but a naked "then:" really doesn't
do it for me.
while 1:
break
then:
print ("Yes!")
while 1:
break
then if not break:
print ("Yes!")
It would be interesting to know what novices thought those meant. Maybe
"if not break:" is not the answer either. I just don't think "then:" is ;)
E.
More information about the Python-list
mailing list