On Thu, May 10, 2018 at 11:17 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > To answer your question from a later post: > > In what way does "while True" in the general case pretend > to be an infinite loop? > > It doesn't *pretend* to be an infinite loop. It *is* an infinite loop > which breaks out early. > > I realise that all infinite loops end up breaking out early, even if it's > only when you power-cycle the device. But code ought to match intent, and > "while condition which can never be false" shouts from the mountain tops > that it is an infinite loop. The simpler the condition, the more loudly > it shouts, and you can't get simpler than True. > > (The one thing that beats "while True" as an indicator of an infinite > loop is the old Hypertalk syntax "repeat forever".)
How about the asyncio event loop's run_forever and run_until_complete methods? run_forever also implies an infinite loop, except that you can stop the event loop at any time. The other choice, run_until_complete, requires that you already know when you want to stop when you call it. Another way of looking at it, run_forever is like a while loop and run_until_complete is like a for loop. So if you know you want to stop the loop at some point, but you don't know when, what do you do to express your intent? > and if we came across it in real life, we'd surely question the sanity of > the developer who wrote it. Why should while loops be any different? > > while True: > if not condition: break # equivalent to GOTO 99 > block > LABEL 99 > > I understand that *today*, using existing Python syntax, there is > sometimes no avoiding that (except, possibly, with something worse). I > get that. But if we had the choice to move the condition into the while > condition, we ought to take it. This is a straw man. As I already replied to Chris, this is not the type of while True I've been arguing for. Obviously in this case the condition should be moved into the while statement. -- https://mail.python.org/mailman/listinfo/python-list
