<div class="gmail_quote">On Sat, Feb 12, 2011 at 8:20 PM,  <span dir="ltr">&lt;<a href="mailto:exarkun@twistedmatrix.com">exarkun@twistedmatrix.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">What part do you think is a hard problem?  Convincing people to switch to a new API?  </div></div></blockquote><div><br></div><div>I think the hard parts is coming up with an API that&#39;s simple enough to learn quickly but powerful enough for to cover most use-cases and cleanly extendable to cover use-cases we haven&#39;t thought of.</div>
<div><br></div><div>If we go with something based on or inspired by Twisted, that solves some problems, but creates others.  Will users be able to later migrate to using Twisted proper?  Will the standard library module and Twisted go out of sync?  What happens if a user tries to use both the standard library module and Twisted?</div>
<div><br></div><div>Please understand that I&#39;m not saying these are insurmountable problems.  I&#39;m just suggesting things that might be good to address in a PEP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">*Defining* the new API doesn&#39;t seem very hard to me.</div></div></blockquote><div> </div></div><meta http-equiv="content-type" content="text/html; charset=utf-8">If you have the skills and experience so that designing a async API is not as hard for you, please run with it.  :-)  Personally, I would love to see asyncore deprecated in favor of something better.<div>
<br>-- <br>Daniel Stutzbach<br>
</div>