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

[Josiah Carlson]

On Thu, Mar 5, 2009 at 3:11 PM,  <glyph at divmod.com> wrote:
>
> On 07:30 pm, nas at arctrix.com wrote:
>>
>> Chris McDonough <chrism at plope.com> wrote:
>>>
>>> As far as I can tell, asyncore/asynchat is all "undocumented
>>> internals".  Any use of asyncore in anger will use internals;
>>> there never was any well-understood API to these modules.
>
>> The implementation requires some intricate and platform specific
>> code which is why it would be nice to be a standard library feature.
>>
>> I'm sure that Twisted has the necessary parts but the problem, IMHO,
>> is that it does so much more else.
>
> ... which is exactly why I have volunteered to explain to someone how to
> separate the core event-loop bits (suitable for inclusion in the standard
> library) from the huge pile of protocol implementations which are not
> necessarily useful.
>
> Despite the FUD to the contrary, Twisted's internal factoring is quite good;
> it's not a single, undifferentiated pile of code.  Plus, at this point,
> we're not even talking about actually putting any Twisted code into the
> standard library, just standardizing the "protocol" API, which basically
> boils down to:
>
>  connectionMade() -> your connection has begun
>  dataReceived(data) -> you got some bytes, handle them
>  connectionLost(reason) -> your connection has gone away (with an object
> explaining why)
>
> and the inverse, "transport", which is:
>
>  write(data) -> deliver some data to the dataReceived on the other end of
> this connection (non-blocking, with buffering)
>  loseConnection() -> goodbye
>
> There are a few other minor details related to how you set these up to talk
> to each other and tell when the out-buffer is empty, but it's all pretty
> straightforward.  The main point is that you don't ever call recv() or
> send() and deal with buffering or handling weird errno values. For example,
> if your connection goes away, the notification you get is "your connection
> went away", not "oops you tried to read some bytes, but your connection was
> gone by the time you tried, even though I just told you it was ready for
> reading" or other similarly obtuse failure modes.

Those "obtuse failure modes" are handled fairly well by asynchat.  It
works pretty well, and includes sample implementations to get you 99%
of the way towards the 5-method API you describe (which is why a lot
of people use asynchat instead of asyncore).  If it weren't for the
fact that asynchat had a previously existing API (including the
.push(), collect_incoming_data(), and found_terminator()), I think it
could stand for methods to make it fit better with asyncore's
handle_*() methods.

 - Josiah