Re: API design for Python 2 / 3 compatibility

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.albasani.net!news.imp.ch!newsfeed.tiscali.ch!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail
From	Stefan Schwarzer <sschwarzer@sschwarzer.net>
Newsgroups	comp.lang.python
Subject	Re: API design for Python 2 / 3 compatibility
Date	Sun, 14 Apr 2013 13:11:59 +0200
Organization	1&1 Internet AG
Lines	43
Message-ID	<516A8EFF.40400@sschwarzer.net> (permalink)
References	<51698989.2070805@sschwarzer.net>
NNTP-Posting-Host	p54b9a130.dip0.t-ipconnect.de
Mime-Version	1.0
Content-Type	text/plain; charset=UTF-8
Content-Transfer-Encoding	7bit
X-Trace	online.de 1365937919 20562 84.185.161.48 (14 Apr 2013 11:11:59 GMT)
X-Complaints-To	abuse@einsundeins.com
NNTP-Posting-Date	Sun, 14 Apr 2013 11:11:59 +0000 (UTC)
User-Agent	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
In-Reply-To	<51698989.2070805@sschwarzer.net>
Xref	csiph.com comp.lang.python:43567

Show key headers only | View raw

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

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

API design for Python 2 / 3 compatibility Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2013-04-13 18:36 +0200
  Re: API design for Python 2 / 3 compatibility Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-13 13:32 -0400
  Re: API design for Python 2 / 3 compatibility Ethan Furman <ethan@stoneleaf.us> - 2013-04-13 11:03 -0700
  Re: API design for Python 2 / 3 compatibility Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2013-04-14 13:11 +0200

csiph-web