On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote:
On 25.06.2015 04:16, Steven D'Aprano wrote:
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
[...]
What is the difference of a function (no awaits) or an awaitable (> 1 awaits) from an end-user's perspective (i.e. the programmer)?
The first is syncronous, the second is asyncronous.
Correct. Main questions to me here: do I, as a caller, need to care?
I think so. If you call a syncronous function when you want something asyncronous, or vice versa, you're going to be disappointed or confused by the result. [...]
# Call func syncronously, blocking until the calculation is done: x = func() # Call func asyncronously, without blocking: y = func()
I think that one of us is missing something here. As I said, I haven't followed the whole discussion, so it might be me. But on face value, I don't think what you say is reasonable.
Ah, wait. That is not what I intended and I completely agree with Guido when he says: "I want to be able to *syntactically* tell where the suspension points are in coroutines." http://code.activestate.com/lists/python-dev/135906/
So, it is either:
# Call func syncronously, blocking until the calculation is done: x = func()
# Call func asyncronously, without blocking: y = await func()
So, from my perspective, no matter, how many (even zero) suspension points there are in func(), the first variant would still be blocking and the second one not.
Where would the function suspend if there are zero suspension points? How can you tell what the suspension points *in* the coroutine are from "await func()"?
Many programmers (when adhering to classical programming) conceive the world as if they call a function and simply do not care about how it works and what it does. The main thing is, it does what it is supposed to do.
Concurrency is not classical single-processing programming.
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).
It might help if you give a concrete example. Can you show a code snippet of your proposal? A single function with zero suspension points being called both asyncronously and syncronously, where does it suspend? It doesn't need to be a big complex function, something simple will do.
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).
I expect that it will be simple to write a wrapper that converts an ayncronous function to a syncronous one. It's just a matter of waiting until it's done. -- Steve