On 10. 02. 22 23:58, Victor Stinner wrote:
Hi,
Would it make sense to move the pythoncapi_compat project under the
GitHub Python or PSF organization to make it more "official" and a
little bit more sustainable?
"The pythoncapi_compat project can be used to write a C extension
supporting a wide range of Python versions with a single code base. It
is made of the pythoncapi_compat.h header file and the
upgrade_pythoncapi.py script."
Documentation: https://pythoncapi-compat.readthedocs.io/en/latest/
GitHub: https://github.com/pythoncapi/pythoncapi_compat
In the past, I managed to move my personal pyperf project under the
PSF organization. Now other core developers are contributing and using
it. It's better than having it as a personal project.
pythoncapi_compat respects the PSF requirements to move a project in
the GitHub PSF organization: contributors are required to respect the
PSF Code of Conduct and the project has 3 maintainers (Dong-hee Na,
Erlend E. AAsland and me).
---
Some context.
Some additional context:
AFAICS, the reason to move it to Python/PSF is to send some kind of
signal. The question is, what kind of signal would that be?
On the SC issue, Victor said
The signal is that the Python core devs bless and trust this project to be a
good solution for the problem that it is trying to solve.
That sounds reasonable.
Do we collectively trust the project?
Or will this send a message that core devs should co-maintain the project?
I personally wouldn't want to maintain it, but it it looks like there
are at least 3 maintainers who do.
Incompatible C API changes in Python 3.10 and 3.11 require adding
compatibility code to write C code compatible with old and new Python
versions.
For example, What's New in Python 3.10 suggests adding the following
code to your project to get the Py_SET_REFCNT() function on Python 3.9
and older:
#if PY_VERSION_HEX < 0x030900A4
# define Py_SET_REFCNT(obj, refcnt) ((Py_REFCNT(obj) = (refcnt)), (void)0)
#endif
Python 3.11 requires even more compatibility functions (7) and the
implementation of these functions take more lines of code:
* Py_SET_TYPE()
* Py_SET_SIZE()
* PyFrame_GetCode()
* PyFrame_GetBack()
* PyThreadState_GetFrame()
* PyThreadState_EnterTracing()
* PyThreadState_LeaveTracing()
Note that PyFrame_* and PyThreadState_* replace API that was previously
private (specifically, documented as subject to change at any time).
I think pythoncapi_compat is a good tool to run if you used code like that!
My opinion on Py_SET_TYPE is that CPython shouldn't make the change
necessary in the first place. But that's in PEP 674, so it's another
discussion.
Note that the upgrade_pythoncapi script uses regular expressions to turn
e.g. all occurences of `something->interp` to
`PyThreadState_GetInterpreter(something)`.
It's fairly simple, but works in practice -- you aren't likely to have
another struct with a `interp` member. IOW, you do need to do a thorough
review after running it, as with a PR from a human contributor. But I
don't think anyone a expects a *fully* automated solution, do they?
The question of maintenance brings op questions about the scope and
backwards compatibility of pythoncapi_compat itself. Currently there's
partial support for Python 2.7, and full for 3.5+. Will the fixes stay
in and accumulate indefinitely?
I added a reference to the pythoncapi_compat project to What's New in
Python 3.11:
"Or use the pythoncapi_compat project to get these functions on old
Python functions."
https://docs.python.org/dev/whatsnew/3.11.html#c-api-changes
The project provides an upgrade_pythoncapi.py script to automatically
add Python 3.10 and 3.11 support without losing support with Python
2.7. Just run the script, maybe copy pythoncapi_compat.h, and you're
done! :-)
It also provides a "pythoncapi_compat.h" header file which contains
all the required compatibility code. Just copy the header file and use
#include "pythoncapi_compat.h"< in your project. You don't have to
maintain this compatibilty code yourself anymore (pythoncapi_compat.h
is made of 400 lines of C code).
pythoncapi_compat supports Python (2.7 to 3.11), PyPy (2.7, 3.6, 3.7)
and C++. It is distributed under the MIT license.
My concern is that currently the project lives in my
https://github.com/pythoncapi organization which is not really a
sustainable option for the future.
Why? (That's an honest question.)
I have a similar project (just header, not automation) for py2->py3
transition under my *personal* account, and it seems to have been pretty
succesful: https://py3c.readthedocs.io/en/latest/
---
The pythoncapi_compat project is used by more and more Python
projects, like Mercurial or mypy:
https://pythoncapi-compat.readthedocs.io/en/latest/users.html
I already made a similar request in June 2021 (move the project under
the PSF organization):
https://mail.python.org/archives/list/python-dev@python.org/thread/KHDZGCNOYEDUTSPAATUDP55ZSSQM5RRC/
What changed since June 2021? Python 3.11 now requires way more
compatibility code than Python 3.10 does: 7 functions instead of 1.
On Discord, I was asked to ask the Steering Council. I asked the SC
who asked me to ask on python-dev, so here I am :-)
Note that there was no official communication from the SC, just
clarifying questions and discussions from individuals who happen to be
on the SC (and who were -- at least in my case -- thinking about what
should go into a SC decision).
Anyway, it would be great if the SC could just rubber-stamp a consensus
here :)
_______________________________________________
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/TITKTPNYV6SNT2IOOQMDXYILKVW6IDZY/
Code of Conduct: http://python.org/psf/codeofconduct/
