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

[Laurens Van Houtven]

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.
- It requires a lot of very experienced manpower.
- 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.


> --
> --Guido van Rossum (python.org/~guido)
>

-- 
cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121013/d464c57a/attachment.html>