Logged In: YES 
user_id=516066

Push() sending data may indeed be the source of the problems here. There 
should be no problems with delaying the write until the next select() will tell 
the socket is writable.

My current work around is indeed subclassing as you describe. However, it 
seemed that such a thing would be exactly that: a work around in order to 
obtain expected behaviour.

So a suggestion: push() should either not try to send, or should communicate 
back to its caller when an error occurs. Having an error handler set an error 
code to check is so 80s, but that could be just me :)

Maybe push() not sending is the nicer of the two solutions. There is little 
reason why it can't wait till the next select() call returns the socket as 
writable.

If nothing is changed, the documentation should contain that handle_error() 
can be triggered even though one is only adding stuff to a FIFO buffer (or so 
the description of push() makes it seem). Reading the docs doesn't prepare 
you for the control flow as I first described. In all the other handle_error 
invocations, handle_error() isn't called from within your code unless you raise 
exceptions in your part of the handle_read/write/accept/connect code. Even 
in asyncore, send() gives you an exception instead, creating an inconsistency 
with asynchat's push(), as both can fail.