On Friday, December 18, 2015 1:09 PM, Guido van Rossum <gu...@python.org> wrote:
>I guess we could make the default arg to sleep() 1e9. Or make it None and >special-case it. I don't feel strongly about this -- I'm not sure how baffling >it would be to accidentally leave out the delay and find your code sleeps >forever rather than raising an error (since if you don't expect the infinite >default you may not expect this kind of behavior). Yeah, that is a potential problem. The traditional C solution is to just allow passing -1 to mean "forever",* ideally with a constant so you can just say "sleep(FOREVER)". Which, in Python terms, would presumably mean "asyncio.sleep(asyncio.forever)", and it could be a unique object or an enum value or something instead of actually being -1. * Or at least "until this rolls over 31/32/63/64 bits", which is where you get those 49-day bugs from... but that wouldn't be an issue in Python > But I do feel it's not important enough to add a new function or method. Definitely agreed. >However, I don't think "forever" and "until cancelled" are really the same >thing. "Forever" can only be interrupted by loop.stop(); "until cancelled" >requires indicating how to cancel it, and there the OP's approach is about the >best you can do. (Or you could use the Event class, but that's really just a >wrapper on top of a Future made to look more like threading.Event in its API.) OK, I thought the OP's code looked pretty clear as written: he wants to wait until cancelled, so he waits on something that pretty clearly won't ever finish until he's cancelled. If that (or an Event or whatever) is the best way to spell this, then I can't really think of any good uses for sleep(forever). _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
