How coding in Python is bad for you

[Erik]

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.