[Python-Dev] Another 2.4 asyncore headache

[Tim Peters]

[Jeremy Hylton]
> I don't understand the use case or the correct intended use of
> asyncore <wink>, but
>    e = r + w
> looks appealing.  It allows object to be in the socket map without
> requiring that they be ready to do some kind of I/O at any instant
> that select is called.

It's enough that the Zope tests pass again, but I don't know Andrew's
intended use case.  The patch certainly changed visible semantics in
one of the major apps indulging major asyncore abuse.

Playing along with asyncore's emergent design, all along it passed
something X in the read set iff X.readable() said "yup", and likewise
for the write set wrt X.writable().  If there's a use case for passing
things in the exception set too, the backward-compatible way would
have been to do that iff a new X.exceptionable() said "yup", with a
default implementation that always said "no".  That would have slowed
asyncore some for everyone, but if the use case isn't strong enough to
justify a slowdown, perhaps the use case isn't strong enough period.