Honestly the changes in Python 3 should not be any obstacle to porting code. Most of it winds up being a find and replace. The major difference is the use of unicode, and if your package really depends heavily on strings not being unicode, you probably did it wrong. The problem is that if one package that lots of people depend on has devs that just say, "I don't wanna," everything breaks down. And more than one package has devs like that.
At this point, if the Python community could make "porting" as simple as adding a header to a .py file, there would still be people that would refuse to do it.
The problem with Python 3 "unicode" is not that text is not Unicode. The problem is that *random binary data* is not Unicode, but when you read data from an unknown source, you MUST assume it is "random binary data". Trusting it to follow some pattern is by far the stupidest thing you can do.
In Python 2 you could put random binary data into a "string" and then write it to disk without any change, and no errors would be produced. Only if you tried to *display* the string would you get an exception. In Python 3 it will immediately throw an exception, at a completely useless point in your program (ie when you are reading data in, not when you are processing it). Changing every "string" to a "bytes" will "fix" it, but then you have to change the type of every single function that is called from "string" to "bytes", and so on, eventually replacing every single "string" in your program with "bytes". And you are out of luck if one of those api's is from a library that you don't control.
Python 3 will NEVER get accepted unless you can put totally arbitrary patterns of 8-bit data into a "string" and get them back out unchanged. All exceptions must be deferred until something actually tries to split the data into Unicode code points. Even then they should be providing a more useful iterator based api that returns an object that says "the code point is this" or "there is a UTF-8 parsing error here and the first byte is this".