[Python-ideas] The async API of the future: PEP 3153 (async-pep)

[Calvin Spealman]

On Sat, Oct 13, 2012 at 1:54 PM, Laurens Van Houtven <_ at lvh.cc> wrote:
> On Sat, Oct 13, 2012 at 1:22 AM, Guido van Rossum <guido at python.org> wrote:
>>
>> [Hopefully this is the last spin-off thread from "asyncore: included
>> batteries don't fit"]
>>
>> So it's totally unfinished?
>
>
> At the time, the people I talked to placed significantly more weight in
> "explain why this is necessary" than "get me something I can play with".
>
>>
>> > Do you feel that there should be less talk about rationale?
>>
>> No, but I feel that there should be some actual specification. I am
>> also looking forward to an actual meaty bit of example code -- ISTR
>> you mentioned you had something, but that it was incomplete, and I
>> can't find the link.
>
>
> Just examples of how it would work, nothing hooked up to real code. My
> memory of it is more of a drowning-in-politics-and-bikeshedding kind of
> thing, unfortunately :) Either way, I'm okay with letting bygones be bygones
> and focus on how we can get this show on the road.
>
>> > It's not that there's *no* reference to IO: it's just that that
>> > reference is
>> > abstracted away in data_received and the protocol's transport object,
>> > just
>> > like Twisted's IProtocol.
>>
>> The words "data_received" don't even occur in the PEP.
>
>
> See above.
>
> What thread should I reply in about the pull APIs?
>
>>
>> I just want to make sure that we don't *completely* paint ourselves into
>> the wrong corner when it comes to that.
>
>
> I don't think we have to worry about it too much. Any reasonable API I can
> think of makes this completely doable.
>
>> But I'm really hoping you'll make good on your promise of redoing
>> async-pep, giving some actual specifications and example code, so I
>> can play with it.
>
>
> Takeaways:
>
> - The async API of the future is very important, and too important to be
> left to chance.

Could not agree more.

> - It requires a lot of very experienced manpower.

I'm sitting on the sidelines, wishing I had much of either, because of
point number 1.

> - It requires a lot of effort to handle the hashing out of it (as we're
> doing here) as well as it deserves to be.
>
> I'll take as proactive a role as I can afford to take in this process, but I
> don't think I can do it by myself. Furthermore, it's a risk nobody wants to
> take: a repeat performance wouldn't be good for anyone, in particular not
> for Python nor myself.
>
> I've asked JP Calderone and Itamar Turner-Trauring if they would be
> interested in carrying this forward professionally, and they have
> tentatively said yes. JP's already familiar with a large part of the problem
> space with the implementation of the ssl module. JP and Itamar have worked
> together for years and have recently set up a consulting firm.
>
> Given that this is emphatically important to Python, I intend to apply for a
> PSF grant on their behalf to further this goal. Given their experience in
> the field, I expect this to be a fairly low risk endeavor.

I like this idea. There are some problems spare time isn't enough to solve.

I can't think of many people as qualified for the task.

>>
>> --
>> --Guido van Rossum (python.org/~guido)
>
>
> --
> cheers
> lvh
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy