[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 2020-01-30 07:12, Dima Tisnek wrote: On Fri, 24 Jan 2020 at 00:27, Victor Stinner 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? ___ Python-Dev mailing list -- python-dev@pyth
[Python-Dev] Static inline functions in header files, limited API and the stable ABI
Hi,
Is it ok to add a static inline function to the limited API? Can it
cause ABI issue? Or is it safer to add a regular function? For
example, is it safe to add the following function to the limited API?
static inline PyObject *
_PyObject_CallOneArg(PyObject *func, PyObject *arg)
{
...
return _PyObject_VectorcallTstate(tstate, func, args, nargsf, NULL);
}
Or should it be an opaque definition like the following function?
PyAPI_FUNC(PyObject *) PyObject_CallNoArgs(PyObject *func);
I came to this question while reviewing "Make Vectorcall public" C API:
https://bugs.python.org/issue39245
https://github.com/python/cpython/pull/17893
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/P7RURGS4ZG4RVKEVFFP36BP6BUU6CBX5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Static inline functions in header files, limited API and the stable ABI
Victor Stinner wrote:
> Hi,
> Is it ok to add a static inline function to the limited API? Can it
> cause ABI issue? Or is it safer to add a regular function? For
> example, is it safe to add the following function to the limited API?
> static inline PyObject
> _PyObject_CallOneArg(PyObject func, PyObject *arg)
> {
> ...
> return _PyObject_VectorcallTstate(tstate, func, args, nargsf, NULL);
> }
> Or should it be an opaque definition like the following function?
> PyAPI_FUNC(PyObject ) PyObject_CallNoArgs(PyObject func);
Yes, it should need the opaque definition. Otherwise we'd need to ensure
ABI compatibility for _PyObject_VectorcallTstate and we would need to
support the exact definition of the static inline function "forever".
> I came to this question while reviewing "Make Vectorcall public" C API:
> https://bugs.python.org/issue39245
> https://github.com/python/cpython/pull/17893
Just to clarify, that PR does not propose adding things to the limited API.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/O4NI45WC64EBET65AN6FZIRBYIRRKAHD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 613 Accepted
The Steering Council has considered Guido’s request for pronouncement on PEP 613 - Explicit Type Aliases, written by Shannon Zhu and sponsored by Guido van Rossum. The Council unanimously accepts PEP 613. Congratulations! We’ll leave it to the sponsor and author to update the PEP accordingly. -Barry (on behalf of the Python Steering Council) signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/COK5SWSHIK433FZT2X6AUTN7RY3NPLA7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
Dima Tisnek writes: > 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? Python 2 is still very much alive (even in a Python 3 venv :-þ): (analysis.venv) 01 16:56$ /usr/bin/python Python 2.7.10 (default, Feb 22 2019, 21:55:15) [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D We have stopped supporting Python 2 in the sense that we are no longer going to release source updates to Python 2. That doesn't necessarily mean we don't consider the needs of users who continue to depend on Python 2 for one reason or another, excellent or totally (in our oh-so-ever-'umble opinion) mistaken though that reason may be. > Ofc., my assumption could be just wrong... It might be, it might not be, it might be situation-dependent (ie, decisions should be made case by case on a cost to Python core developers versus benefits to Python 2 users and those who support them in their libraries etc basis). I think it would certainly be reasonable to make the decision that we're going to go full speed ahead with Python 3 and start stripping out Python 2-only features in the stdlib code. I don't support that, but I'm not a core developer, so that's a +1.0e-17 for keeping the code. I get the feeling that Guido is also not in favor of a Procrustean[1] approach to Python 2 support in the Python 3 stdlib, but I could be wrong. Since he's not BDFL, that's merely indicative, but IMO it's a pretty strong indicator. What would really distress me however, is if we forget that we're not supporting *code*, we're supporting *users* by creating and maintaining code. Of course we can choose that user base, and may have to make painful decisions. But this community is about people supporting people, just like any community. Footnotes: [1] Look up "Procrustes" in Wikipedia. It's not a story to tell in this family setting. ;-) ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/ Code of Conduct: http://python.org/psf/codeofconduct/
