On 10/09/2021 16:36, MRAB wrote:

>> while...else...
>>
>> executes the else if the body of the loop does NOT get executed.
>>
>> for...else...
>>
>> executes the else iff ALL iterations of the for loop DO complete.
>>
> [snip]
>
> In both cases, it executes the 'else' part if it didn't break out of the
> loop. That's it.

OK, That's a useful perspective that is at least consistent.

Unfortunately it's not how beginners perceive it and it causes
regular confusion about how/when they should use else with a loop.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

Alan Gauld <alan.gauld@yahoo.co.uk> writes:
>OK, That's a useful perspective that is at least consistent.
>Unfortunately it's not how beginners perceive it
....

Beginners perceive it the way it is explained to them by
their teacher.

On 10/09/2021 19:49, Stefan Ram wrote:
> Alan Gauld <alan.gauld@yahoo.co.uk> writes:
>> OK, That's a useful perspective that is at least consistent.
>> Unfortunately it's not how beginners perceive it
> ...
>
> Beginners perceive it the way it is explained to them by
> their teacher.

I'm not sure that's true. Most beginners, in my experience,
learn the syntax from their teachers and then go off and play.
What they observe happening is what sticks. And python loop
'else' constructs appear inconsistent to them.

As teachers we like to think we are passing on our wisdom
to our students but in reality everyone learns from their
own experience. The teachers advice is just the starting
point. Hopefully, that starting point sends them in the
right direction but that's the best we can hope for.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

Alan and others,

I think human languages used to make computer languages will often cause
confusion.

Some languages have an IF .. ELSE construct but also an EITHER ... OR and a
NEITHER ... NOR and other twists and turns like words that sometimes come
apart and you end up having to dangle a part that was in the front of a word
to later in the sentence and so on.

But I suspect many languages do NOT naturally have a construct like:

WHILE ... ELSE.

The might have a sentence like "While it is sunny you should use sunscreen
but when it rains use an umbrella." It probably is even a tad deceptive to
use WHILE in one part and not in the other. Perfectly valid sentences are
"When going outside if it is sunny use sunscreen but if it is rainy use an
umbrella" or skip the while and use a more standard if/else. The world
"while" just does not feel like a partner for "else".

So say you want to have a loop starting with WHILE and FOLLOWED by a single
ELSE clause. Arguably you could make WHILE as a construct return a status of
sorts if it runs at all or perhaps if it exits after at least one iteration
because the condition evaluates to FALSE. It would either return false if
you exit with a BREAK or by an error or perhaps not exit at all if you do a
return from within.

So if you made up a syntax like:

IF (WHILE condition {...})
ELSE {...}

Then what would that mean? Again, this is a make-believe construct. In the
above, if WHILE returned a True of some sort, the else is skipped.
Otherwise, no matter what has been done within the while loop, it is done.

But as noted we have odd choices here potentially. Could we differentiate
between a BREAK statement within and something like BREAK OK variant that
means the while is to be treated as succeeded and please do not do the
trailing ELSE? I can see many possible ways to design things and cannot
expect humans to automatically assume the specific nomenclature will be
meaningful to them.

There is an alternative that people who are not damn sure what the meaning
is can do. Create a variable that is set to False or True to represent
something before the WHILE is entered. Then make sure your code flips that
value in cased you want to make sure a trailing statement is run. Then
following the while, you place an IF statement that tests that variable and
does what the ELSE cluse would have done, or not.

Looking at other constructs, look at this code with a try:

i=0
while i<5:
try:
assert(i!=3) #Raises an AssertionError if i==3
print("i={0}".format(i))
except:
continue
finally:
i+= 1; #Increment i

Now attach an ELSE clause to the WHILE, LOL!

At some point, van some humans decide just not to write the code this way?

What about code that uses CONTINUE to the point where you enter the WHILE
statement and get a secondary IF or something that keeps triggering a
CONTINUE to start the next iteration. Arguably, this can effectively mean
the WHILE loop did nothing. An example would be evaluating the contents of a
data structure like a list and adding all numeric items together and
ignoring any that are character strings. Given all characters, no summation
is done. The first statement in the loop tests a list item and does a
CONTINUE. But by the rules as I see them, the loop was entered. Yet, a
similar loop written where the WHILE condition simply tests if ANY item is
numeric, might drop right through to an ELSE clause.

Bottom line is humans do not all think alike and language constructs that
are clear and logical to one may be confusing or mean the opposite to
others.

I can even imagine designing an interface like this:

WHILE (condition):
...
IF_NOT_RUN:
...
IF_EXITED_EARLY:
...
IF_ERROR_THROWN:
...
ON_PREMATURE_RETURN_DO_THIS:
...

I am not suggesting we need critters like that, simply that ELSE is a grab
bag case that can mean many things to many people.

But if the specific meaning is clearly documented, use it. Lots of people
who program in languages like Python do not necessarily even speak much
English and just memorize the keywords.

We can come up with ever more interesting or even bizarre constructs like
multiple WHILE in a row with each one being called only if the previous one
failed to process the data. An example might be if each tests the data type
and refuses to work on it so the next one in line is called. That could
perhaps be done by having multiple ELSE statements each with another WHILE.
But is that an ideal way to do this or perhaps instead use some variant of a
switch statement or a dictionary pointing to functions to invoke or
something.

Time to go do something lese of even minor usefulness!

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Alan Gauld via Python-list
Sent: Saturday, September 11, 2021 3:59 AM
To: python-list@python.org
Subject: Re: Friday Finking: Contorted loops

On 10/09/2021 19:49, Stefan Ram wrote:
> Alan Gauld <alan.gauld@yahoo.co.uk> writes:
>> OK, That's a useful perspective that is at least consistent.
>> Unfortunately it's not how beginners perceive it
> ...
>
> Beginners perceive it the way it is explained to them by
> their teacher.

I'm not sure that's true. Most beginners, in my experience, learn the
syntax from their teachers and then go off and play.
What they observe happening is what sticks. And python loop 'else'
constructs appear inconsistent to them.

As teachers we like to think we are passing on our wisdom to our students
but in reality everyone learns from their own experience. The teachers
advice is just the starting point. Hopefully, that starting point sends them
in the right direction but that's the best we can hope for.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

--
https://mail.python.org/mailman/listinfo/python-list

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Alan Gauld <alan.gauld@yahoo.co.uk> writes:
>>OK, That's a useful perspective that is at least consistent.
>>Unfortunately it's not how beginners perceive it
> ...
>
> Beginners perceive it the way it is explained to them by
> their teacher.

My life as a professor would have been *so* much easier if that were
true...

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> My life as a professor would have been *so* much easier if that were
> true...

From Ed Nelson, "Reflections on retirement",
https://web.math.princeton.edu/~nelson/papers/retirement.pdf :

Teaching freshman calculus is fun, but it poses very different
challenges from graduate teaching. A few years ago while grading the
final exam, I felt an increasing sense of frustration that I couldn’t
articulate. Finally I was able to put it into words: “I’ve been teaching
these kids forty years and still they don’t understand!”

Il 11/09/2021 22:29, Avi Gross ha scritto:
>
> Alan and others,
>
> I think human languages used to make computer languages will often cause
> confusion.
>
> Some languages have an IF .. ELSE construct but also an EITHER ... OR and a
> NEITHER ... NOR and other twists and turns like words that sometimes come
> apart and you end up having to dangle a part that was in the front of a word
> to later in the sentence and so on.
>
> But I suspect many languages do NOT naturally have a construct like:
>
> WHILE ... ELSE.
>
> The might have a sentence like "While it is sunny you should use sunscreen
> but when it rains use an umbrella." It probably is even a tad deceptive to
> use WHILE in one part and not in the other. Perfectly valid sentences are
> "When going outside if it is sunny use sunscreen but if it is rainy use an
> umbrella" or skip the while and use a more standard if/else. The world
> "while" just does not feel like a partner for "else".
>
> So say you want to have a loop starting with WHILE and FOLLOWED by a single
> ELSE clause. Arguably you could make WHILE as a construct return a status of
> sorts if it runs at all or perhaps if it exits after at least one iteration
> because the condition evaluates to FALSE. It would either return false if
> you exit with a BREAK or by an error or perhaps not exit at all if you do a
> return from within.
>
> So if you made up a syntax like:
>
> IF (WHILE condition {...})
> ELSE {...}
>
> Then what would that mean? Again, this is a make-believe construct. In the
> above, if WHILE returned a True of some sort, the else is skipped.
> Otherwise, no matter what has been done within the while loop, it is done.
>
> But as noted we have odd choices here potentially. Could we differentiate
> between a BREAK statement within and something like BREAK OK variant that
> means the while is to be treated as succeeded and please do not do the
> trailing ELSE? I can see many possible ways to design things and cannot
> expect humans to automatically assume the specific nomenclature will be
> meaningful to them.
>
> There is an alternative that people who are not damn sure what the meaning
> is can do. Create a variable that is set to False or True to represent
> something before the WHILE is entered. Then make sure your code flips that
> value in cased you want to make sure a trailing statement is run. Then
> following the while, you place an IF statement that tests that variable and
> does what the ELSE cluse would have done, or not.
>
> Looking at other constructs, look at this code with a try:
>
> i=0
> while i<5:
> try:
> assert(i!=3) #Raises an AssertionError if i==3
> print("i={0}".format(i))
> except:
> continue
> finally:
> i+= 1; #Increment i
>
> Now attach an ELSE clause to the WHILE, LOL!
>
> At some point, van some humans decide just not to write the code this way?
>
> What about code that uses CONTINUE to the point where you enter the WHILE
> statement and get a secondary IF or something that keeps triggering a
> CONTINUE to start the next iteration. Arguably, this can effectively mean
> the WHILE loop did nothing. An example would be evaluating the contents of a
> data structure like a list and adding all numeric items together and
> ignoring any that are character strings. Given all characters, no summation
> is done. The first statement in the loop tests a list item and does a
> CONTINUE. But by the rules as I see them, the loop was entered. Yet, a
> similar loop written where the WHILE condition simply tests if ANY item is
> numeric, might drop right through to an ELSE clause.
>
> Bottom line is humans do not all think alike and language constructs that
> are clear and logical to one may be confusing or mean the opposite to
> others.
>
> I can even imagine designing an interface like this:
>
> WHILE (condition):
> ...
> IF_NOT_RUN:
> ...
> IF_EXITED_EARLY:
> ...
> IF_ERROR_THROWN:
> ...
> ON_PREMATURE_RETURN_DO_THIS:
> ...
>
> I am not suggesting we need critters like that, simply that ELSE is a grab
> bag case that can mean many things to many people.
>
> But if the specific meaning is clearly documented, use it. Lots of people
> who program in languages like Python do not necessarily even speak much
> English and just memorize the keywords.
>
> We can come up with ever more interesting or even bizarre constructs like
> multiple WHILE in a row with each one being called only if the previous one
> failed to process the data. An example might be if each tests the data type
> and refuses to work on it so the next one in line is called. That could
> perhaps be done by having multiple ELSE statements each with another WHILE.
> But is that an ideal way to do this or perhaps instead use some variant of a
> switch statement or a dictionary pointing to functions to invoke or
> something.
>
> Time to go do something lese of even minor usefulness!
>
> -----Original Message-----
> From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
> Behalf Of Alan Gauld via Python-list
> Sent: Saturday, September 11, 2021 3:59 AM
> To: python-list@python.org
> Subject: Re: Friday Finking: Contorted loops
>
> On 10/09/2021 19:49, Stefan Ram wrote:
>> Alan Gauld <alan.gauld@yahoo.co.uk> writes:
>>> OK, That's a useful perspective that is at least consistent.
>>> Unfortunately it's not how beginners perceive it
>> ...
>>
>> Beginners perceive it the way it is explained to them by
>> their teacher.
>
> I'm not sure that's true. Most beginners, in my experience, learn the
> syntax from their teachers and then go off and play.
> What they observe happening is what sticks. And python loop 'else'
> constructs appear inconsistent to them.
>
> As teachers we like to think we are passing on our wisdom to our students
> but in reality everyone learns from their own experience. The teachers
> advice is just the starting point. Hopefully, that starting point sends them
> in the right direction but that's the best we can hope for.
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>

An inconsistency that I have been able to notice is this:
someone suggests to remedy the absence of the do-while with:
while True:
...
if condition:
break
the problem arises if the while has an else of its own because the break
not only blocks the while loop but will also ignore the relative else.

-- snip --
>
> An inconsistency that I have been able to notice is this:
> someone suggests to remedy the absence of the do-while with:
> while True:
>      ...
>      if condition:
>          break
> the problem arises if the while has an else of its own because the break
> not only blocks the while loop but will also ignore the relative else.
>

I will try to make my doubt clearer:
if the only way to terminate a 'while True' loop is by using the 'break'
statement, why is it allowed to add the 'else' statement which will only
contain dead code?

while True:
break
else:
print('dead code')

On Sun, 12 Sep 2021 10:11:15 +0200, jak wrote:

> -- snip --
>>
>> An inconsistency that I have been able to notice is this:
>> someone suggests to remedy the absence of the do-while with:
>> while True:
>>      ...
>>      if condition:
>>          break
>> the problem arises if the while has an else of its own because the
>> break not only blocks the while loop but will also ignore the relative
>> else.
>>
>>
> I will try to make my doubt clearer:
> if the only way to terminate a 'while True' loop is by using the 'break'
> statement, why is it allowed to add the 'else' statement which will only
> contain dead code?
>
> while True:
> break
> else:
> print('dead code')

Because adjusting the parser for one specific special case is not worth
the effort.
it is not the job of the interpreter to sanitise stupid programming

"Special Cases aren't special enough the break the rules"

--
If you stew apples like cranberries, they taste more like prunes than
rhubarb does.
-- Groucho Marx

On 12/09/2021 09:11, jak wrote:

> if the only way to terminate a 'while True' loop is by using the 'break'
> statement, why is it allowed to add the 'else' statement which will only
> contain dead code?
>
> while True:
> break
> else:
> print('dead code')
>
Because to the interpreter the condition is not part of the
language. It is syntactically correct.

An optimiser OTOH might welkl determine that the condition
will never fail and therefore the else clause never be reached,
in which case it would remove the dead code (possibly emitting
a warning in the process?).

A linter likewise might identify the redundant code.
I don't use any python linters, does anyone know if they do
detect such dead spots?

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos