On Fri, 24 Jan 2020 at 00:27, Victor Stinner <vstin...@python.org> wrote:
> Miro and me consider that Python 3.9 is pushing too much pressure on > projects maintainers to either abandon Python 2.7 right now... Let's not conflate py2 EOL with what-should-go-into-py39. > https://copr.fedorainfracloud.org/coprs/g/python/python3.9/monitor/ > - Has package failures. Some packages fail because of broken dependencies. Please provide a better summary. I've looked at first 3 failed packages, and: * `afflib` only has these error lines: ``` warning: extra tokens at the end of %endif directive in line 186: %endif # with_python2 warning: extra tokens at the end of %endif directive in line 195: %endif # with_python3 ``` I don't know if that's why the build is considered failed, but that issue seems to be on the build script side. * `python-django-post_office` doesn't have any stderr output or other indication why the build failed. * `ansible-lint` same, does this package even use Python? > https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39 > - Has open Python 3.9 bug reports for Fedora packages. Some problems I feel it's still early days for py39 and well-maintained packages are expected to catch up. I, for one, just started testing our crud against py39a3 yesterday, and yes some tools and libraries are broken, so I've opened issues and might post a PR, depending. I get the gist from your email that you are (or fedora folks are) doing the same. So, what's the rationale to change py39 change set? > try: > from collections.abc import Sequence > except ImprotError: > # Python 2.7 doesn't have collections.abc > from collections import Sequence I thought that collections compatibility was kept up to 3.8 specifically because py2 was alive. No that that requirement is gone, so should the shim, right? Ofc., my assumption could be just wrong... > While if we remove collections.Sequence in 3.10, they will face this > decision early in 2021 and they will simply fix their code by adding > ".abc" at the proper places, not needing any more compatibility > layers. Of course, there will be projects that will still have > declared Python 2 support in 2021, but it will arguably not be that > many. I see some semi-abandoned projects, as well as actively maintained projects not addressing DeprecationWarnings. I don't know if some projects just need a harder push (will break, not just deprecated). Either way, my gut tells me, if py39 was changed and became very compatible, we'd see the same discussion in 2021. > * Removed tostring/fromstring methods in array.array and base64 modules > * Removed collections aliases to ABC classes > * Removed fractions.gcd() function (which is similar to math.gcd()) > * Remove "U" mode of open(): having to use io.open() just for Python 2 > makes the code uglier > * Removed old plistlib API: 2.7 doesn't have the new API my 2c: all of these are truly minor. I have a feeling that the discussion is just wrong altogether. It should not be "let's remove" or "let's keep". It should not be "let's keep x but not y". It should be something along the lines of: * here's a great tool that fedora has that shows which libraries need changes (your links + better output) * here's a build server, where existing packages (maybe not fedora) can be tested and built on py39, new ABI, etc. * [optional] it would be awesome if anyone could submit their repo url and the server would automatically build wheels for all arch,abi and publish to pypi * let's notify package maintainers (presumably done?) and if that doesn't yield the desired result, * let's organise the open-source community (via fame or bounties) and fix (or fork) those that are important (common [transitive] deps to many fedora packages) Cheers, d. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AGR66AM2FXBG7URXC6KZDOY3HLSKMDC4/ Code of Conduct: http://python.org/psf/codeofconduct/
