[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

Guido van Rossum guido at python.org
Wed Mar 4 19:04:21 CET 2009


On Tue, Mar 3, 2009 at 9:31 PM,  <glyph at divmod.com> wrote:
>
> On 3 Mar, 10:20 pm, guido at python.org wrote:
>>
>> On Tue, Mar 3, 2009 at 1:17 PM,  <glyph at divmod.com> wrote:
>
>>> At the very least, this might serve as a basis for an abstract API for
>>> asyncore:
>>>
>>>
>>> http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html
>
>> I hope we have learned from asyncore that a future-proof and maximally
>> flexible design of such an API is not easy. This is one of those cases
>> where I believe thinking hard up front will really pay off. In this
>> case I would recommend going through a full-blown PEP process before
>> committing to an API, to avoid making the same mistake twice. (I don't
>> mean this as a dig at Twisted, just as an observation about this
>> particular design problem. If Twisted solves all the problems already,
>> writing the PEP should be easy.)
>
> I didn't see it as a dig at Twisted; you're right, this is a hard problem.
>  Twisted doesn't solve all the problems perfectly, either; much has been
> made of some rather unfortunate nuances of the IProducer and IConsumer
> interfaces.
>
> I also regret that no Twisted people (myself included) seem to have the time
> to go through the PEP process and get something accepted.

Same here.

> Even if Twisted's interfaces aren't perfect, there's a lot of working
> application code which demonstrates that they are sufficient.  Perhaps more
> importantly, they are future-proof.  Every proposal we've come up with for
> addressing the more subtle shortcomings of these APIs has been completely
> backwards-compatible; there are no APIs with vague or broken semantics, just
> sub-optimal spellings.  The fact that there are already multiple reactor
> implementations which share very little code helps.

Sounds like it's not so much the code that's future proof but the
process used for evolving it. That seems to be missing for asyncore.
:-(

> If someone who has PEP-writing skills and some free time is updating
> asyncore to be more modern, I'd be very happy to walk that person through
> Twisted's API design and explain how either portions of our implementation
> could be lifted for the stdlib, or how a "high level" layer could be written
> into asyncore so that the author of a particular chunk of low-level
> networking code could ignore whether they're using the stdlib mainloop or
> one of the Twisted ones.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list