> That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2.
The "horrible hacking" already exists bundled into libraries and tools like Six and Future.
> split it in two seperate packages.
That was tried, and failed every time. Because now you end up with two diverging and hard to reconcile code bases. A single-source cross-version library, while not trivial (and not allowing the user of more advanced P3 features) works way better.
> The "horrible hacking" already exists bundled into libraries and tools like Six and Future.
Only for the simplest cases. How is Six going to help you write a regex that matches emoji, for example?
On Python 3 you write a range that includes the emoji you want to match, and you're done. On Python 2, that regex may or may not compile, depending on what sys.maxunicode is. If sys.maxunicode is 65535 you have to fall back on a different complicated regex that has a bunch of cases to find emoji in their UTF-16 representation. If you want to avoid that system-specific behavior, you can I guess encode it to UTF-8 bytes and write an extremely complicated regex that finds emoji in UTF-8.
This is my prime example about how something that's easy on Python 3 can require horrible hacking on Python 2. A wrapper library doesn't fix that problem.
Python 2 and 3 have different semantics, and the only way a correct, automated translation between them would be possible would be to emulate one inside the other.
The "horrible hacking" already exists bundled into libraries and tools like Six and Future.
> split it in two seperate packages.
That was tried, and failed every time. Because now you end up with two diverging and hard to reconcile code bases. A single-source cross-version library, while not trivial (and not allowing the user of more advanced P3 features) works way better.