Terry, Ethan: Thanks a lot for your excellent advice. :-)
On 2013-04-13 19:32, Terry Jan Reedy wrote: > Approach 2 matches (or should match) io.open, which became > builtin open in Python 3. I would simply document that > ftp_host.open mimics io.open in the same way that > ftp_host.chdir, etcetera, match os.chdir, etc. Your > principle will remain intact. I didn't know about `io.open` (or had forgotten it). > Anyone writing *new* Py 2 code with any idea of ever > running on Py 3 should be using io.open anyway. That is > why it was backported. You might be able to reuse some io > code or subclass some io classes for your implementation. Since I use `socket.makefile` to create the underlying file objects, I can use `BufferedReader`/`BufferedWriter` and `TextIOWrapper` to supply buffering and encoding/decoding. On 2013-04-13 20:03, Ethan Furman wrote: > Approach 2, because it is much saner to deal with unicode > inside the program, and only switch back to some kind of > encoding when writing to files/pipes/etc. Yes, this is a much saner design. I just was hesitant because of the introduced backward incompatibility and wanted to get other's opinions. > Since you are going to support python 3 as well you can > bump the major version number and note the backward > incompatibility. Actually I plan to increase the version number from 2.8 to 3.0 because of the Python 3 support and already intend to change some module names that will be visible to client code. So this is also a good opportunity to clean up the file interface. :) Best regards, Stefan -- http://mail.python.org/mailman/listinfo/python-list
