Re: [Python-ideas] Updating PEP 315: do-while loops
Mike Meyer wrote:
This is just arguing about the meaning of "syntactic sugar". In some sense, almost all control constructs are syntactic sugar, as all you really need is lambda and if (http://en.wikipedia.org/wiki/Lambda_Papers). However, anything that lets me reduce the line count by removing boilerplate or - even better, duplicate code - moves out of that category for me. Please feel free to disagree.
Then by your own definition do/while has yet to move out of the category of "syntactic sugar". do/while does not reduce line count, and if it could be said to remove boilerplate or duplicate code it does so to a vanishingly small degree. So what's left? My working definition of "syntactic sugar" is: "likely-redundant syntax that makes expressing a program more appealing somehow". I think do/while is syntactic sugar. Is it worth making the language bigger to add it? Particularly when we can't agree on what would be good syntax? The fact that we're still having the debate implies... well, that people like arguing on the internet I guess. But do/while can be found in Pascal, and C / C++, and all the C clones (Java, C#) cloned that too, so perhaps it has merit. Anyway, this is one reason why I like the "do:" statement I proposed. (The other one--the one where I also proposed "continue if" and "break if". But given your reaction to those let's ignore 'em for now.) This isn't *pure* sugar--it's a mildly novel flow control construct for structured programming. Certainly Python doesn't have anything like it right now; "while True:" isn't an exact match (and "while False:" is equivalent to "if 0:"). My "do:" would allow spelling do/while as: do: something() if condition: continue I think that's a reasonable do/while, and so economical: we only added one new keyword. This form of "do:" has other uses too, as per my previous email. Not that I expect this syntax to take the world by storm.
do: something() while condition
Except Guido has already rejected this - or at least stated that he doesn't really like it.
I can believe that. I still think it's as good as we're going to do for a literal translation of do/while. If there was a syntax everyone liked we'd already be using it. The fact that we haven't hit on one by now--recall that the PEP is six years old--implies that we're not likely to find one. We've added lots of syntax to Python over the last six years, stuff that has made the language more powerful, more flexible, and even faster in some places. do/while doesn't give us any new power, flexibility, or speed--I daresay if we never added do/while we wouldn't really miss it. If you have it handy, can you cite where he said he didn't like that? Not that I don't believe you; I'd just like to read it. Has Guido cited a syntax that he *did* like? /larry/
On 26 Apr 2009, at 21:20, Larry Hastings wrote:
Anyway, this is one reason why I like the "do:" statement I proposed. (The other one--the one where I also proposed "continue if" and "break if". But given your reaction to those let's ignore 'em for now.) This isn't *pure* sugar--it's a mildly novel flow control construct for structured programming. Certainly Python doesn't have anything like it right now; "while True:" isn't an exact match (and "while False:" is equivalent to "if 0:"). My "do:" would allow spelling do/while as:
do: something() if condition: continue
I think that's a reasonable do/while, and so economical: we only added one new keyword. This form of "do:" has other uses too, as per my previous email.
Not that I expect this syntax to take the world by storm.
It's funny because I had something like this in mind when I myself suggested 'break if ...' and 'continue if ...' a little while ago (although I would go for a 'loop:' that doesn't need to be continue'd explicitely). I had come to the point of view that the restrictions of the looping construct had in fact somehow liberated it and made it more versatile by making if condition: break and if condition: continue common control flow constructs inside a while loop, that in particular encompass the do ... while / repeat ... until constructs, etc seen in other languages (I may have expressed myself better in the original thread). My motivation for 'break/continue if ...' was that it would make those constructs stand out more (and could be hilighted clearly as such in editors) - I was a bit surprised when I was told it would make code less readable and that it was a slippery slope, but then I have lots of ideas, most of which don't turn out to be very good :) -- Arnaud
Because I can't resist: do-while diddy diddy dum diddy do -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair
On Sun, Apr 26, 2009 at 6:15 PM, Aahz <aahz@pythoncraft.com> wrote:
Because I can't resist:
do-while diddy diddy dum diddy do
+1 QOTW - Chris
-- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair
Arnaud Delobelle wrote:
On 26 Apr 2009, at 21:20, Larry Hastings wrote:
Anyway, this is one reason why I like the "do:" statement I proposed. (The other one--the one where I also proposed "continue if" and "break if". But given your reaction to those let's ignore 'em for now.) This isn't *pure* sugar--it's a mildly novel flow control construct for structured programming. Certainly Python doesn't have anything like it right now; "while True:" isn't an exact match (and "while False:" is equivalent to "if 0:"). My "do:" would allow spelling do/while as:
do: something() if condition: continue
I think that's a reasonable do/while, and so economical: we only added one new keyword. This form of "do:" has other uses too, as per my previous email.
Not that I expect this syntax to take the world by storm.
It's funny because I had something like this in mind when I myself suggested 'break if ...' and 'continue if ...' a little while ago (although I would go for a 'loop:' that doesn't need to be continue'd explicitely). I had come to the point of view that the restrictions of the looping construct had in fact somehow liberated it and made it more versatile by making
if condition: break
and
if condition: continue
common control flow constructs inside a while loop, that in particular encompass the do ... while / repeat ... until constructs, etc seen in other languages (I may have expressed myself better in the original thread). My motivation for 'break/continue if ...' was that it would make those constructs stand out more (and could be hilighted clearly as such in editors) - I was a bit surprised when I was told it would make code less readable and that it was a slippery slope, but then I have lots of ideas, most of which don't turn out to be very good :)
I think it would help it to stand out. while 1: ... if a == 2: b = finished if b == 3: breakit() if c == 4: break if d == 5: baker = name if e == 6: steak = done while 1: ... if a == 2: b = finished if b == 3: breakit() break if c == 4 if d == 5: baker = name if e == 6: steak = done Ron
A quick summary of my views: 1. When I programmed in C, I hardly if ever used do...while. I have read that this is true of other C coders also. So I see no need for a Python equivalent. 2. On the other hand, loop and a half use is a regular occurrence. Anything that does not arguably improve while True: part1() if cond: break part2() such as loop part1() whhile not cond: part2() seems pretty useless. But even the above does not work great for multiple "if... break"s and not at all for "if...continue". 3. I do not see 'if cond: break' as that much of a problem. One can emphasize with extra whitespace indent or comment. if cond: break #EXIT# In any case, I see it as analogous to early return def f(): part1() if cond: return part2() and while there are purists who object to *that*, I have not seen any proposals to officially support better emphasis (other than the existing whitespace or comment mechanisms). In fact, it is not uncomment to use 'return expr' instead of 'ret=expr; break' when a loop (for or while) is the last part of a def. 4. "do ... while cond:" strikes me as ugly. Aside from that, I do not like and would not use anything that puts the condition out of place, other than where it is executed. I would hate to read such code and expect it would confuse many others. 5. We well never reach consensus. PEP 315 might as well be withdrawn. Terry Jan Reedy
On 27 Apr 2009, at 18:49, Terry Reedy wrote:
A quick summary of my views:
1. When I programmed in C, I hardly if ever used do...while. I have read that this is true of other C coders also. So I see no need for a Python equivalent.
I haven't got much C that I wrote myself, but on my most recent C project, out of 100 loops: * 65 are while loops * 31 are for loops * 4 are do-while loops In the py3k C source, out of 100 loops I see: * 60 for loops * 32 while loops * 8 do-while loops
2. On the other hand, loop and a half use is a regular occurrence. Anything that does not arguably improve
while True: part1() if cond: break part2()
such as
loop part1() whhile not cond: part2()
seems pretty useless. But even the above does not work great for multiple "if... break"s and not at all for "if...continue".
This is my opinion also.
3. I do not see 'if cond: break' as that much of a problem. One can emphasize with extra whitespace indent or comment. if cond: break #EXIT#
In any case, I see it as analogous to early return
def f(): part1() if cond: return part2()
and while there are purists who object to *that*, I have not seen any proposals to officially support better emphasis (other than the existing whitespace or comment mechanisms).
My idea with 'break/continue if' was, in my mind, such a proposal. I thought that it would enshrine what I perceived as a very common construct ('if ...: break/continue') into the language and make it easier to spot when scanning code.
In fact, it is not uncomment to use 'return expr' instead of 'ret=expr; break' when a loop (for or while) is the last part of a def.
4. "do ... while cond:" strikes me as ugly. Aside from that, I do not like and would not use anything that puts the condition out of place, other than where it is executed. I would hate to read such code and expect it would confuse many others.
I definitely agree with this. -- Arnaud
Terry Reedy wrote:
But even the above does not work great for multiple "if... break"s and not at all for "if...continue".
Personally I don't care at all about that. This is about providing a clearly structured way to write the most common case. As soon as you have multiple breaks you've already got one foot in spaghetti-land and any notion of clean structure has gone out the window. -- Greg
Terry Reedy wrote:
A quick summary of my views:
1. When I programmed in C, I hardly if ever used do...while. I have read that this is true of other C coders also. So I see no need for a Python equivalent.
2. On the other hand, loop and a half use is a regular occurrence. Anything that does not arguably improve
while True: part1() if cond: break part2()
such as
loop part1() whhile not cond: part2()
seems pretty useless. But even the above does not work great for multiple "if... break"s and not at all for "if...continue".
I agree. I don't see lack of do--while as a wart.
3. I do not see 'if cond: break' as that much of a problem. One can emphasize with extra whitespace indent or comment. if cond: break #EXIT#
In any case, I see it as analogous to early return
def f(): part1() if cond: return part2()
and while there are purists who object to *that*, I have not seen any proposals to officially support better emphasis (other than the existing whitespace or comment mechanisms).
In fact, it is not uncomment to use 'return expr' instead of 'ret=expr; break' when a loop (for or while) is the last part of a def.
The 'break if'/'continue if' would make the break and continue more visible in some cases, but I now realize it also is limited to a single line rather than a block. ... if exit_cond: ... ... break ... Break and continue are pretty visible as long as they are on a line by themselves, so maybe we should just stick with what we have.
4. "do ... while cond:" strikes me as ugly. Aside from that, I do not like and would not use anything that puts the condition out of place, other than where it is executed. I would hate to read such code and expect it would confuse many others.
I agree.
5. We well never reach consensus. PEP 315 might as well be withdrawn.
Unless there is some very nice examples or performance reasons to show otherwise, I just don't see enough need to be a convincing change. Ron
participants (8)
-
Aahz -
Arnaud Delobelle -
Chris Rebert -
Greg Ewing -
Larry Hastings -
Raymond Hettinger -
Ron Adam -
Terry Reedy