The future import technique works well for syntax changes which only affect a single module.
It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3.
But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present?
In principle there could be a wrapper to present the correct API. However, that's complicated, and not interesting compared to, say, a new methods for doing asynchronous programming.
This sort of backwards compatibility can be done. I've heard about IBM doing it for ... REXX, perhaps? .. where a program and perhaps even a module could declare which version to use. But it's expensive. And despite its popularity, there aren't scores of companies paying millions of dollars to ensure this level of compatibility,
For the bytes vs char, maybe you can make it more gradual : make unicode possible and non default (py2), make it possible, non default but deprecate raw strings literals, make unicode literals default one year after. Not TEN.
Or maybe JUST make it the ONLY check to go from python 2.7 to 2.8 and focus on supporting the change during one whole year.
Or provide both APIs - maybe as a compile time switch- but all the new APIs using text would be unicode only.
Wait for all libs to change focusing on just that. Make developers go 10 times that amount of verifications and changes.
Python had incompatible changes before so it wasn't a "take any 1.2 python code and it runs on py 1.5.2" level backwards compatibility (by example : string exceptions, new keywords ..). There hasn't been any drama for this, not ten-year level one at least. My point was that maybe py3 transition could have been smoother had it be done this way - it's very difficult to handle, and shall be glad to have the python 3.6+ we have now anyway)
It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3.
But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present?
In principle there could be a wrapper to present the correct API. However, that's complicated, and not interesting compared to, say, a new methods for doing asynchronous programming.
This sort of backwards compatibility can be done. I've heard about IBM doing it for ... REXX, perhaps? .. where a program and perhaps even a module could declare which version to use. But it's expensive. And despite its popularity, there aren't scores of companies paying millions of dollars to ensure this level of compatibility,