On 2020-01-30 07:12, Dima Tisnek wrote:
On Fri, 24 Jan 2020 at 00:27, Victor Stinner <vstinner@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.
Those are just warnings; ignore them. afflib didn't build because it's missing a dependency (libtermcap-devel). It wasn't counted in the ones with Python-related problems.
* `python-django-post_office` doesn't have any stderr output or other indication why the build failed.
Same situation (this time missing python3-django-jsonfield).
* `ansible-lint` same, does this package even use Python?
And that one is missing python3-passlib, which fails several tests; one of them being ImportError: cannot import name 'MutableMapping' from 'collections'.
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.
Definitely! That's exactly what we're doing: helping the well-maintained packages catch up, via bug reports and pull requests as capacity allows. And now we're reporting back that the most common change these packages have to make is the collections.abc removal, and that since many projects are planning to drop py2 compat later in 2020, the pull request we need to send is ugly -- and it could be much nicer one-liner in 2021 if the collections.abc removal was postponed.
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.
Not really. For projects that want to stay be py2/py3-compatible for the long term, the long "try/except ImportError" dance makes sense.
* 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)
Yes! Except a few details, that's just what I'd like to do in the long term. Do you want to help?