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