On 01:49 pm, [email protected] wrote: >Should I file a bug? If so, any guidelines what to do?
This report isn't sufficiently complete to decide if this is a bug in Twisted or in something else. You really cannot send unicode over a socket without encoding it. The question to consider here is the question of whose responsibility it should be to do that encoding in this case. >[snip] > >[autobahn@autobahnhub ~/Twisted]$ svn diff twisted/protocols/ftp.py >Index: twisted/protocols/ftp.py >=================================================================== >--- twisted/protocols/ftp.py (revision 33225) >+++ twisted/protocols/ftp.py (working copy) >@@ -382,7 +382,7 @@ > self._onConnLost.callback(None) > > def sendLine(self, line): >- self.transport.write(line + '\r\n') >+ self.transport.write(str(line) + '\r\n') This isn't the correct fix, even if the bug is in Twisted's FTP support. `str(line)` is the least reliable way to encode a unicode string into a byte string. It has unpredictable behavior (it relies on the action- at-a-distance API, `sys.setdefaultencoding`, which doesn't even exist most of the time, but which can be used to completely change what `str(unicode)` does). A more correct solution would be `line.encode(someencoding)`. However, looking at `sendLine`, it's clear that the value of `someencoding` is not easily decided upon. Should it be UTF-8? ASCII with an error replacement policy? cp1252? Does it depend on the client, or the server, or the filesystem encoding, or a user preference? An even more correct solution would be for `line` to have been encoded properly already before it was passed to `sendLine`. Where did the data come from, and why wasn't it encoded already? Jean-Paul _______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
