And we don't actually mind all that much if applications don't migrate
in the near term - Python 2 will have commercial support available
well past 2020. (The developers of *those applications* might mind,
The group we *do* really care about supporting is authors of existing
Python *libraries*, and "2in3" and "3in2" approaches don't really help
them at all, since library and framework authors with users on both
Python 2 and Python 3 will likely face demand to support both versions
natively anyway.


Lets assume  for the moment that the 'we don't really care about the 60% of python developers blocked from moving to python 3 by depencies' was not really what you meant.

I am going to assume that what you really meant was 'I do not think helping these people directly is the best solution'.
And this attitude is based around the fear that if the developers can move to python 3 before the libraries all support python 3, then that will remove pressure from the libraries to support python 3.

This fear i can understand.  But I suggest some real world experience shows this approach is actually not assisting either group.  It is certainly not assisting the developers wishing to move to python 3, but it is also making life hard for the "people we do really care about"

So not supporting a "2in3" solution forces programmers to with python2 dependencies to hold off moving to python3 until their dependencies migrate, but hopefully with sound motives.

Now take a typical dependency.  Web2py.  Speak to them on migration and they will telly you 'none of our users have moved to python 3'.  So the users are held back from moving by the dependencies, and the dependencies are held back by the users.

I would suggest that making it easier to support both python2 and ptyhon3 from a library is simply reducing what it a painful thing.  I would suggest that allowing all the end users to migrate to python3 as soon as possible is a far more attractive solution.