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