Saying new versions will not be Python 2 compatible is not a request for Companies to upgrades. It's just a statement that they will be stuck on old version of libraries, unless they buy* support for a vendor.

We (the IPython team) have no objection if Continuum or Enthought provide a Paying version of IPython 6.x that is Python 2 compatible, but that's their problem. It does not prevent either the core developer of the Python-3 only project to consult on potential Python 2 internal fork.

I honestly think that this would be a much sane model that would make both sides of the Py2vsPy3 battle happy.

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()"

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

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.

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

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.

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.)

The end of life of python 2, and the end of python 2 support in popular libraries isn't "a damn good reason"?

The cost is justified if you want to use a supported language.

Obviously when I say "I will support it", I don't mean myself, single-handedly. I mean my company. Or someone else's company. The point is, commercially speaking, nobody cares about official PSF support. The world will go on unaffected, with or without it.