Message70593
| Author |
josiahcarlson |
| Recipients |
benjamin.peterson, djarb, giampaolo.rodola, janssen, josiah.carlson, josiahcarlson |
| Date |
2008年08月01日.21:20:01 |
| SpamBayes Score |
0.00010279945 |
| Marked as misclassified |
No |
| Message-id |
<1217625604.42.0.581597751481.issue1563@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|