Ethan Furman wrote: > On 06/26/2015 08:47 AM, Steve Dower wrote: >> On 06/26/2015 06:48 AM, Sven R. Kunze wrote: >> >>> def business(): >>> return complex_calc(5) >>> >>> def business_new() >>> return await complex_calc(10) > >> Assuming "async def business_new" (to avoid the syntax error), there's no >> difference between those functions or the one they're calling: >> >> * "complex_calc" returns an awaitable object that, after you've awaited it, >> will result in an int. >> * "business" returns the return value of "complex_calc", which is an awaitable >> object that, after you've awaited it, will result in an int. >> * "business_new" returns an awaitable object that, after you've awaited it, >> will result in an int. >> >> In all three of these cases, the result is the same. The fact that the >> awaitable object returned from any of them is implemented by a coroutine isn't >> important (in the same way that an iterable object may be implemented by a >> generator, but it's really irrelevant). > > What? Shouldn't 'business_new' return the int? It did await, after all. I assumed "async def business_new()", rather than some imaginary "await in a non-async function will block because I love to create deadlocks in my code" feature. Note that blocking prevents *all* coroutines from making progress, unlike threading. When you await all the way to an event loop, it defers the rest of the coroutine until a signal (via a callback) is raised and continues running other coroutines. Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4