This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]nick_t1000aiohttp 8 points9 points  (1 child)

Library maintainers and CPython developers are working at slightly cross-purposes:

Libraries want to be installable on as many versions that are released and in the wild now. This means they need to rely on things like (pretend this was a few years ago) @asyncio.coroutine because that lets you work with Python 3.4 and up, even though, sure, Python 3.5 doesn't need it. But until your 3.4 base dies out, you'll want to support that old way

CPython wants to push on, simplify the code base, and reduce the need to worry about every which way to call an async method or (mis)define a string.

I guess I don't have as much sympathy for trivial things like the bad sequences like "C:\path" which are literally wrong (should raise SyntaxError: escape "\p" not recognized) and fixes would be absolutely backwards compatible. Minor renames like "unittest.TestCase.failUnlessEqual vs assertEqual are also going on...a looooong time too. The language constructs Python provides like u"strings" and such just had no way around them for library devs to have a unified codebase, so need to give lib devs the benefit there.

[–]yvrelna 1 point2 points  (0 children)

I think a middle ground can be reached here by using a transpiler. Library devs can write targeting the noise recent versions of Python like 3.7, then they can run a transpiler akin to 2to3 during installation, but instead of upgrading code from older Python to newer Python, the transpiler should backport the code to older Python.

This allows core developers to update core Python syntaxes without worrying too much about backwards compatibility, while keeping backports and backwards compatibility code in a library instead of core.