[Python-Dev] Another 2.4 asyncore headache (original) (raw)
Tim Peters tim.peters at gmail.com
Mon Aug 16 03:44:19 CEST 2004
- Previous message: [Python-Dev] Another 2.4 asyncore headache
- Next message: [Python-Dev] Decorator syntax J2 (decorate..def), with implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Jeremy Hylton]
I don't understand the use case or the correct intended use of asyncore , 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.
- Previous message: [Python-Dev] Another 2.4 asyncore headache
- Next message: [Python-Dev] Decorator syntax J2 (decorate..def), with implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]