API design for Python 2 / 3 compatibility

[Stefan Schwarzer]

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