On Sat, Sep 9, 2017 at 2:19 AM, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: > On Sat, 9 Sep 2017 12:41 am, Chris Angelico wrote: > >>> I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke it >>> for both versions and it was a fairly trivial script. >> >> Show the code that it broke? I've never seen this, unless it's >> something like "now you need to install third-party package X in >> Python 3". The 2to3 transformations are fine for everything in the >> stdlib. > > Chris, I don't think it is controversial that 2to3 occasionally breaks code, > or > fails to translate every feature. Even today, there are still the occasional > bug report or feature request for 2to3.
For "a fairly trivial script", I would like to see how it breaks it. The only thing I've seen that frequently causes trouble is the bytes/text distinction (which, if we're honest, is really just exposing a problem that was already there), and that's only if you have a boundary that can't be trivially resolved eg by adding encoding="utf-8" to your file open calls. > One thing which is notoriously tricky to migrate is mixed bytes/Latin1 text > using Python 2 strings, say you're manipulating file formats that mix text > with > binary bytes. These mixed binary/text files are sometimes badly suited to the > new Unicode/bytes model. Yes - but I don't expect to see a true mixture of binary and textual data in "a fairly trivial script". That sort of thing comes up when you develop parsers for certain network protocols or file formats, but I don't call those "trivial". I should have been more clear about my comment there - that it was specific to the complaint that 2to3 broke a trivial script. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
