On 11. 02. 22 13:52, Victor Stinner wrote:
On Fri, Feb 11, 2022 at 12:06 PM Petr Viktorin <encu...@gmail.com> wrote:
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.
I think that Neal provided a better answer than me :-) It would be
great than once an incompatible C API change is introduced in Python,
pythoncapi_compat is updated. Updating pythoncapi_compat (with unit
tests) ensures that it *is* possible to write a single code base
compatible with old and new Python versions. Sometimes the change can
be modified just a little it to make that transition smoother.
In the past, that's exactly what I did. When I wrote
PyThreadState_EnterTracing(), I started to create a draft PR for
pythoncapi_compat. I merged the pythoncapi_compat PR once the API
landed in Python. I did that for other new C API functions.
All sounds good, I just insist on pointing out that this was only an
incompatible change in the *internal* API.
The functionality of PyThreadState_EnterTracing() was not possible to
get with public API, but enough third parties “cheated”** and used
private API to make it worth writing an automatic updater.
** Or maybe they read an older version of the docs where this wasn't
clear, and then had compatibility expectations changed beneath them. The
way we've been drawing lines between public and private in the past few
years is not entirely fair, but it's the best we have.
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 goal for pythoncapi_compat is to only support new *public*
functions. The *implementation* can use the private API. So C
extensions can use the new clean API and remains compatible with old
Python versions using private structures and private functions.
For example, the PyThreadState_EnterTracing() implementation uses
PyThreadState.cframe.use_tracing (Python 3.10) or
PyThreadState.use_tracing (Python 3.9 and older), and also
PyThreadState.cframe.tracing, whereas the PyThreadState structure is
considered as "private".
// bpo-43760 added PyThreadState_EnterTracing() to Python 3.11.0a2
#if PY_VERSION_HEX < 0x030B00A2 && !defined(PYPY_VERSION)
PYCAPI_COMPAT_STATIC_INLINE(void)
PyThreadState_EnterTracing(PyThreadState *tstate)
{
tstate->tracing++;
#if PY_VERSION_HEX >= 0x030A00A1
tstate->cframe->use_tracing = 0;
#else
tstate->use_tracing = 0;
#endif
}
#endif
Sounds reasonable, but...
The implication of endorsing code like this is that *we cannot change
private API even in patch releases*, which I don't think is documented
anywhere, and might be a bit controversial.
(I'm still planning to document this along with other similar issues, so
if anyone wants to help here, please coordinate with me:
https://discuss.python.org/t/documenting-python-versioning-and-stability-expectations/11090/4).
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?
Right, currently the script uses regex because it's built in Python:
no third party dependency needed. So far, I didn't have to make any
further changes after the script updated a C extension.
In general, only a few lines number of lines are modified by the
script. Less than 50: 5 to 10 lines on most C extensions.
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?
Supporting 2.7 and 3.5 is cheap: the code is already written. I plan
to continue supporting them until it breaks. Once it will no longer be
possible to test these versions, maybe the code can stay, untested,
and bugs would only be fixed if someone proposes a fix.
Makes sense!
Since you're now inviting the wider community as co-maintainers, could
you document this?
It just added Python 3.4 support since it is still possible to get a
Python 3.4 in GitHub Actions (Ubuntu 18.04) :-)
Python 2.7 support is mostly needed by Mercurial which is already
compatible with Python 3. Mercurial plans to drop Python 2 support
soon: in Mercurial 6.2, or maybe even Mercurial 6.1 (the latest
release is 6.0):
https://www.mercurial-scm.org/wiki/Python3
It seems like on Python 3, users target Python 3.6 as the minimum
supported version. Some projects already dropped Python 3.6 support,
move on to Python 3.7.
Victor
_______________________________________________
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/OTLSSOIY4WEKPKJCG4XTTLTJHYL6D6KS/
Code of Conduct: http://python.org/psf/codeofconduct/
