The current revision of 3.0 handles the case where reading from the
socket returns a Python 3.0 str object, which it then translates into
bytes objects.  This is sufficient for passing the 3.0 unittests.  See
asynchat.async_chat.use_encoding and asynchat.async_chat.encoding .

From what I understand, the OP wants to be able to pass unicode strings
across a network connection.  I'm not sure that such is generally
desirable to be within the standard library.  I would actually argue
that being able to transparently pass unicode across a socket is a
misfeature; especially considering 1 unciode character can become 2 or
more bytes when encoded as utf-8, etc., and sockets make no guarantees
about an entire packet being delivered.

In terms of sending (push_str), it should be an error that the user
software is attempting to send textual data (all reasonable RFCs define
protocols in terms of ascii, not utf).  Handling incoming data
(set_terminator_str) follows the same argument against handling unicode
data as push_str, only in reverse.

This should not be backported to any version of Python.


Before discussion about actually applying any patch to
asyncore/asynchat/smtpd continues, I would like to hear of a use-case
for wanting to pass textual unicode data across a socket connection.