<div class="gmail_quote">On Sat, Oct 13, 2012 at 1:22 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[Hopefully this is the last spin-off thread from "asyncore: included<br>
batteries don't fit"]<br>
<br>
So it's totally unfinished?<br></blockquote><div><br>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".<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Do you feel that there should be less talk about rationale?<br>
<br>
No, but I feel that there should be some actual specification. I am<br>
also looking forward to an actual meaty bit of example code -- ISTR<br>
you mentioned you had something, but that it was incomplete, and I<br>
can't find the link.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It's not that there's *no* reference to IO: it's just that that reference is<br>
> abstracted away in data_received and the protocol's transport object, just<br>
> like Twisted's IProtocol.<br>
<br>
The words "data_received" don't even occur in the PEP.<br></blockquote><div><br>See above.<br><br>What thread should I reply in about the pull APIs?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just want to make sure that we don't *completely* paint ourselves into the wrong corner when it comes to that.<br></blockquote><div><br>I don't think we have to worry about it too much. Any reasonable API I can think of makes this completely doable. <br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I'm really hoping you'll make good on your promise of redoing<br>
async-pep, giving some actual specifications and example code, so I<br>
can play with it.<span><font color="#888888"><br></font></span></blockquote><div><br>Takeaways:<br><br>- The async API of the future is very important, and too important to be left to chance. <br>- It requires a lot of very experienced manpower.<br>
- 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.<br><br>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.<br>
<br>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.<br>
<br>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. <br> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</font></span></blockquote></div><br>-- <br>cheers<div>lvh</div><br>