Oh my me. This is a very long thread that I probably should have replied to a long time ago. This thread is intensely long right now, and tonight is the first chance I&#39;ve had to try and go through it comprehensively. I&#39;ll try to reply to individual points made in the thread -- if I missed yours, please don&#39;t be offended, I promise it&#39;s my fault :)<br>

<br>FYI, I&#39;m the sucker who originally got tricked into starting PEP 3153, aka async-pep.<br><br>First of all, I&#39;m glad to see that there&#39;s some more &quot;let&#39;s get that pep along&quot; movement. I tabled it because:<br>

<br>a) I didn&#39;t have enough time to contribute,<br>b) a lot of promised contributions ended up not happening when it came down to it, which was incredibly demotivating. The combination of this thread, plus the fact that I was strong armed at Pycon ZA by a bunch of community members that shall not be named (Alex, Armin, Maciej, Larry ;-)) into exploring this thing again.<br>

<br>First of all, I don&#39;t feel async-pep is an attempt at twisted light in the stdlib. Other than separation of transport and protocol, there&#39;s not really much there that even smells of twisted (especially since right now I&#39;d probably throw consumers/producers out) -- and that separation is simply good practice. Twisted does the same thing, but it didn&#39;t invent it. Furthermore, the advantages seem clear: reusability and testability are more than enough for me.<br>


<br>If there&#39;s one take away idea from async-pep, it&#39;s reusable protocols.<br><br>The PEP should probably be a number of PEPs. At first sight, it seems that this number is at least four:<br><br>1. Protocol and transport abstractions, making no mention of asynchronous IO (this is what I want 3153 to be, because it&#39;s small, manageable, and virtually everyone appears to agree it&#39;s a fantastic idea)<br>

2. A base reactor interface<br>3. A way of structuring callbacks: probably deferreds with a built-in inlineCallbacks for people who want to write synchronous-looking code with explicit yields for asynchronous procedures<br>


4+ adapting the stdlib tools to using these new things<br><br>Re: forward path for existing asyncore code. I don&#39;t remember this being raised as an issue. If anything, it was mentioned in passing, and I think the answer to it was something to the tune of &quot;asyncore&#39;s API is broken, fixing it is more important than backwards compat&quot;. Essentially I agree with Guido that the important part is an upgrade path to a good third-party library, which is the part about asyncore that REALLY sucks right now. Regardless, an API upgrade is probably a good idea. I&#39;m not sure if it should go in the first PEP: given the separation I&#39;ve outlined above (which may be too spread out...), there&#39;s no obvious place to put it besides it being a new PEP.<br>


<br>Re base reactor interface: drawing maximally from the lessons learned in twisted, I think IReactorCore (start, stop, etc), IReactorTime (call later, etc), asynchronous-looking name lookup, fd handling are the important parts. call_every can be implemented in terms of call_later on a separate object, so I think it should be (eg twisted.internet.task.LoopingCall). One thing that is apparently forgotten about is event loop integration. The prime way of having two event loops cooperate is *NOT* &quot;run both in parallel&quot;, it&#39;s &quot;have one call the other&quot;. Even though not all loops support this, I think it&#39;s important to get this as part of the interface (raise an exception for all I care if it doesn&#39;t work).<br>

<br>cheers<br>lvh<br><br>