There are a handful of outstanding asyncore/asynchat related bugs in the tracker.  This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 .In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924.In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them.It adds test cases from patch 909005.It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers.It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method.It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() .It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten.This patch should be applied to the trunk.  The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes).  Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt .

Good work. I would only rencommend to include documentation for asyncore.close_all function, actually not documented yet.

This patch removes two public--and documented--classes from asynchat (simple_producer and fifo).  Even if the proposed changes to asynchat make them utterly worthless, I thought it was general policy to deprecate public items for a release or two before removing them.  Is this the case even when they're as simple as these two classes?

We can leave those two classes in, even though I have never seen them used or subclassed.  In Python 3.x, we can remove them without issue.

The current implementation of asynchat.async_chat.initiate_send methoddoesn't look at what is specified in ac_out_buffer_size attribute whichrepresents the buffer size of the outgoing data defaulting to a maximumof 4096 bytes to send in a single socket.send() call.Note that this only happens when sending the data by using a producerthrough the use of the push_with_producer method.This happens because while the older asynchat version used slicing forbuffering:> num_sent = self.send(self.ac_out_buffer[:obs]) # obs == ac_out_buffer_size...the newer version just calls self.send using the entire data asargument without caring of what ac_out_buffer_size thinks about it:> num_sent = self.send(first)What is specified in ac_out_buffer_size when using a producer is justignored and the only way to have control over the outgoing data bufferis to operate directly on the producer.

In attachment I provide a patch for fixing this last mentioned issue.It's a rewriting of initiate_send method which now looks at what isspecified by ac_out_buffer_size attribute.

I've discussed a lot with Josiah via e-mail and this is the updatedversion of the patch including a fix for the two issues raised before.This update has been needed also because the original patch has beenout-dated by some commits afterr53734 involving the test suiteand the documentation, which I both took off this patch.I also re-added simple_producer and fifo classes in asynchat.py since itseems they are needed for passing tests.The test suite has passed on Windows XP using Python 2.6 alpha 1.I have also successfully run the test suite of a project of mine basedon asynchat which includes over 40 tests.

Are there news about this issue?

In attachment the Josiah Carlson's patch who currently seems to haveproblems in accessing the bug tracker.It should address all the problems raised on python-dev related discussion:http://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/40e79742231076b9?lnk=gst&q=asyncore#40e79742231076b9

This is separate fromissue1563, right?

Yes.

FWIW, I've added Giampaolo's latest patch to Rietveld:http://codereview.appspot.com/744Review comments added there should automatically be CC'ed here.

Dearreport@bugs.python.org,New code review comments bygvanrossum@gmail.com have been published.Please go tohttp://codereview.appspot.com/744 to read them.Message:(This is mostly a test of the bug/rietveld integration.)Details:http://codereview.appspot.com/744/diff/1/22FileDoc/library/asyncore.rst (right):http://codereview.appspot.com/744/diff/1/22#newcode226Line 226: A file_dispatcher takes a file descriptor or file object along with an optionalMind keeping the line length under 80 chars?Issue Description:http://bugs.python.org/issue1736190Sincerely,  Your friendly code review daemon (http://codereview.appspot.com/).

Dear GvR, report,New code review comments by josiah.carlson have been published.Please go tohttp://codereview.appspot.com/744 to read them.Message:Details:http://codereview.appspot.com/744/diff/1/22FileDoc/library/asyncore.rst (right):http://codereview.appspot.com/744/diff/1/22#newcode226Line 226: A file_dispatcher takes a file descriptor or file object along with an optionalOn 2008/05/05 22:02:22, GvR wrote:> Mind keeping the line length under 80 chars?No problem.  Any other comments?Issue Description:http://bugs.python.org/issue1736190Sincerely,  Your friendly code review daemon (http://codereview.appspot.com/).

Committed to trunk a bit ago, will be in 3.0 this weekend.

This issue should be closed.