Josiah Carlson <[EMAIL PROTECTED]> added the comment: 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. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1563> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
