This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: while else loop seems to behave incorrectly
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.0, Python 2.6, Python 2.5
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, mark, mark.dickinson
Priority: critical Keywords:

Created on 2008-01-24 13:22 by mark, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
while.patch amaury.forgeotdarc, 2008-01-24 16:41
Messages (6)
msg61629 - (view) Author: Mark Summerfield (mark) * Date: 2008-01-24 13:22
I am using:

Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
IDLE 3.0a1 

This seems wrong:

>>> while False:
	print("no")
else:
	print("yes")

	
>>> 

I expected it to print "yes" because the docs say that the else suite is
executed if present and if the loop terminated normally (no break), and
this is the case here.

This works though:

>>> x = False
>>> while x:
	print("no")
else:
	print("yes")

	
yes
>>> 

So it seems that "while False" and "while variable" are giving different
behaviour.
msg61632 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-01-24 13:42
python 2.5 has the same behaviour, if you use "while 0:" instead.
In compiler.c, there is code that optimizes away blocks like "if 0",
"while 0". 'if' correctly emit the else clause, 'while' does not...
msg61634 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-24 16:00
This bug is also present in the trunk, with while 0 instead of while 
False.

This appears closely related to issue #1875.

In my opinion this is a serious bug in the core language.  I'm not sure 
whether it's serious enough to be considered a showstopper for 2.5.2.  
In any case, I'm raising the priority to get more eyes on this before 
2.5.2.
msg61639 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-01-24 16:41
Here is a patch, made against py3k; it should apply cleanly to the trunk.

On the 2.5 branch, compile.c seems identical, but test_grammar.py looks
very different; the conversion should be easy.

Can someone review and apply it? I don't have svn access at the moment.
msg61667 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-25 02:27
Looks like Amaury found his svn access.  Is it okay to close this now?
msg61670 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-25 03:59
Forgot to say:  Amaury checked his fix in in revision #60265 (trunk) and 
revision #60268 (Python 2.5).

Thanks for the bug report, Mark!
History
Date User Action Args
2022-04-11 14:56:30adminsetgithub: 46215
2008-01-25 03:59:32mark.dickinsonsetmessages: + msg61670
2008-01-25 02:27:52mark.dickinsonsetstatus: open -> closed
resolution: accepted
messages: + msg61667
2008-01-24 16:41:29amaury.forgeotdarcsetfiles: + while.patch
messages: + msg61639
2008-01-24 16:00:52mark.dickinsonsetpriority: critical
nosy: + mark.dickinson
messages: + msg61634
versions: + Python 2.6, Python 2.5
2008-01-24 13:42:45amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg61632
2008-01-24 13:22:47markcreate