[Python-ideas] An async facade? (was Re: [Python-Dev] Socket timeout and completion based sockets)

[Christian Tismer]

On 30.11.12 20:29, Guido van Rossum wrote:
> On Fri, Nov 30, 2012 at 11:18 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> Guido van Rossum wrote:
>>> Futures or callbacks, that's the question...
>> I know the C++ standards committee is looking at the same thing right now, and they're probably going to provide both: futures for those who prefer them (which is basically how the code looks) and callbacks for when every cycle is critical or if the developer prefers them. C++ has the advantage that futures can often be optimized out, so implementing a Future-based wrapper around a callback-based function is very cheap, but the two-level API will probably happen.
> Well, for Python 3 we will definitely have two layers already:
> callbacks and yield-from-based-coroutines. The question is whether
> there's room for Futures in between (I like layers of abstraction, but
> I don't like having too many layers).

So far I agree very much.
> ...

> The debate is still open.
>> How about:
>>
>> value, future = obj.some_call(...)
>> if value is None:
>>      value = yield future
> Also considered; I don't really like having to allocate a tuple here
> (which is impossible to optimize out completely, even though its
> allocation may use a fast free list).

A little remark:

I do respect personal taste very much, and if a tuple can be avoided
I'm in fore sure.
But the argument of the cost of a tuple creation is something that even I
no longer consider relevant, especially in a context of other constructs
like yield-from which are (currently) not even efficient ( O(n)-wise ).

The discussion should better stay design oriented and not consider
little overhead by a constant factor.

But I agree that returned tuples are not a nice pattern to be used all 
the time.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/