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 _______________________________________________ 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
