On Fri, Feb 26, 2016 at 3:11 AM, Stefan Scherfke <[email protected]> wrote: > >> Am 2016-02-25 um 12:33 schrieb Andrew Svetlov <[email protected]>: >> >> Why do you hesitate to use loop members? > > No, I don’t hesitate. I’m just wondering why some functions are exposed > as loop members and some are normal functions taking a loop argument. > Why the different namespaces? > It's question of code coupling. Functions that require access to loop internal state are loop members. Ones that can be built on top of existing loop members are just first class functions/coroutines.
>> I found passing explicit loop is very important and should be done >> everywhere. > > I agree. In SimPy, we even went so far to not have an implicit, global > default loop (we call it Environment). Thus, you *must* pass the > environment explicitly around. > >> asyncio.TimeoutError cannot be inherited from TimeoutError builtin: >> the former has no errno and technically it is not an OSError > > Actually, the asyncio TimeoutError is not really an error, but imho > rather something like an interrupt (like "KeyboardInterrupt", which is > also not called "KeyboardInterruptError"), so just "asyncio.Timeout" (or > maybe "asyncio.TimeoutInterrupt") would maybe we more appropriate. > Historically Guido van Rossum made asyncio.TimeoutError as just alias for concurrent.Future.TimeoutError. That makes sense. Unfortunately it clashes with builtin TimeoutError, but looks like the ship has sailed two years ago. Renaming concurrent.Future.TimeoutError and asyncio.TimeoutError to TimeoutInterrupt will make a mess (we still need to support old names for several Python releases). > Cheers, > Stefan > >> >> On Thu, Feb 25, 2016 at 5:01 AM, Stefan Scherfke >> <[email protected]> wrote: >>> HI Martin, >>> >>>> Am 2016-02-25 um 09:44 schrieb Martin Teichmann >>>> <[email protected]>: >>>> >>>> Hi list, >>>> >>>> first of all, I wanted to thank all the authors of asyncio. It's just >>>> great, and makes my life as a programmer so much easier! >>> >>> Yep. :) >>> >>>> >>>> There is just one thing I have problems with: the naming of >>>> the functions is, well, awkward. For long I thought that it's >>>> just my poor English, but recently I have been introducing >>>> asyncio to a coworker who is native english speaker, and >>>> when I told him: if you want to run two coroutines ham and >>>> spam in parallel, just write >>>> >>>> await gather(ham(), spam()) >>> >>> “There are only two hard things in Computer Science: cache invalidation >>> and naming things.” >>> >>> -- Phil Karlton >>> >>> I guess some of the confusion comes from replacing "yield from" with >>> "await". To me, "yield from gather(...)" doesn’t sound as strange as >>> "await gather(...)". >>> >>>> So, I arbitrarily propose to introduce new names. Maybe >>>> some native speaker comes up with even better names. >>>> >>>> gather -> parallel >>>> wait -> first_completed, first_exception and all_completed >>>> wait_for -> timed >>>> ensure_future -> create_task >>> >>> In SimPy, a descrete-event simulation lib with similar concepts as >>> asyncio, we also had long discussions about naming stuff when we wrote >>> version 3. >>> >>> For stuff like "gather()" and "wait_for()", we introduced so called >>> "Condition Events" and created "any_of()" and "all_of()" methods around >>> it. "await all_of(fut1, fut2)" or "await any_of(fut1, fut2)" reads a >>> lot better then "gather()", imho. >>> >>> Instead of a timeout parameter, we simply would do a "await any_of(fut1, >>> sleep(x))" (actually, in SimPy, "sleep()" is called "timeout()"). >>> >>> And, even better, you could use the "&" and "|" operators to concatenate >>> futures/events: "await fut | timeout" or "await fut1 & fut2". >>> >>> Instead of "create_task()" or "async()" we use "process()" to indicate >>> that we start a new "sub process", but "create_task()" would be fine to >>> if it was in the "asyncio" namespace and not a method of loop. >>> >>> That some methods (e.g., "gather()") are in the "asyncio" namespace and >>> require a loop argument and some methods are methods of a loop instance >>> itself also baffles me. >>> >>> Unfortunately, the problem with asyncio is, that it is in the stdlib >>> and you cannot just start renaming stuff, or only with long deprecation >>> periods. >>> >>> Cheers, >>> Stefan >>> >> >> >> >> -- >> Thanks, >> Andrew Svetlov > -- Thanks, Andrew Svetlov
