Sven R. Kunze wrote: > # Call func syncronously, blocking until the calculation is done: > x = func() > > # Call func asyncronously, without blocking: > y = await func() Using the word "blocking" this way is potentially confusing. The calling task is *always* blocked until the operation completes. The difference lies in whether *other* tasks are blocked or not. > Whether this function achieves the goal by working asynchronously or > blocking, AND if I, as a programmer, allow the function to work > asynchronously, is a completely different matter. That in turn is > extremely well reflected by the 'await' keyword (IMHO at least). > > > > Another issue that bothers me, is code reuse. Independent from whether > the 'async def' makes sense or not, it would not allow us to reuse > asyncio functions as if they were normal functions and vice versa (if I > understood that correctly). You understand correctly. If the function is declared async, you must call it with await; if not, you must not. That's not ideal, but it's an unavoidable consequence of the way async/await are implemented. > So, we would have to implement things twice > for the asyncio world and the classic world. Not exactly; it's possible to create a wrapper that takes an async function and runs it to completion, allowing it to be called from sync code. I can't remember offhand, but there's likely something like this already in asyncio. > One last thing regarding 'async def', that came to my mind recently, is > that it compares to that necessity of Java to decorate functions with > all possible exceptions that could be raised inside. It's a similar situation, but nowhere near as severe. There are only two possibilities, async or not. Once you've converted a function to async, you won't need to change it again on that score. -- Greg
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