[orf]

> I HAVE worked on transitioning several large codebases from 2 to 3 and in each case this has been months of work, incurring completely unjustified costs

Out of interest whats the biggest time sink while doing this? I've had a lot of luck using 2to3 and with decent test coverage and a UAT environment that people can access, its not exactly months and months of work changing "xrange" to "range", and "print" to "print()"

[avian]

> decent test coverage

You were indeed very lucky if all projects you've worked on had decent test coverage.

[nas]

The unicode/bytes change it the most time consuming in my experience. Second comes the fact that you can't sort arbitrary types anymore and that None is no longer smaller than any other value.

In order to ease porting, I've created a modified Python 3.6 interpreter that generates warnings in a lot of the cases that real Python 3 would generate an exception. See https://github.com/nascheme/ppython .

The goal is to have a 2to3 script that generates something that will run, with warnings, under me modified Python. Once you fix all the warnings, your code should run correctly in Python 3.

[orf]

> Second comes the fact that you can't sort arbitrary types anymore

Surely that's a bug in the system that you've just uncovered and fixed? Py2 used to use the memory address of the object when comparing by default, which is just... crazy, especially for a language with so few WTFs:

   >>> object() > object()
   True
   >>> object() > object()
   False
   >>> object() > object()
   True
   >>> object() > object()
   False

> In order to ease porting, I've created a modified Python 3.6 interpreter

That looks amazing! We're going to end up porting a fairly large + critical Django app to py3 and I definitely think this could ease some of the pain. I'm going to give it a go when I get the chance.

[dragonwriter]

> Py2 used to use the memory address of the object when comparing by default, which is just... crazy,

Its true that that's crazy, but, OTOH, everything-can-be-sorted is a useful feature (which Erlang has, for instance). Py3 could conceptually have retained it with a different implementation (this would probably still have been a breaking change from Py2, but not a feature loss.)

[crdoconnor]

For me it's been libraries which we rely upon which don't support 3.

[orf]

True, I didn't consider the cost of updating packages (and any associated API changes). But in my experience there are very few packages that simply don't support Python 3, and the ones that don't are just dead.

[ATsch]

http://py3readiness.org looks pretty good, most of the blockers for me (like twisted and a few others) are gone by now.

[wiz21c]

care to give some examples ?