On 08.09.2021 14:40, Victor Stinner wrote:
Hi,
On Wed, Sep 8, 2021 at 2:10 PM Marc-Andre Lemburg <mal@egenix.com> wrote:
I believe that such breaking changes need to follow the standard PEP 387 procedure.
While your pythoncapi_compat project is nice, I don't think C extension writers will appreciate breaking changes in new releases without the two minor release announcement and warning phase.
This is especially important with the new shorter release cycle.
Emitting compiler warnings was discussed multiple times, but so far, nobody manages to write a macro which only emits a warning if it's used as an l-value "Py_TYPE(...) = ...".
Yes, that's a difficult one, indeed.
Py_REFCNT() macro was already converted to a static inline function in Python 3.10. This change went fine. It only broke like 1 or 2 projects.
As you mentioned yourself, the Py_TYPE() change does break quite a few projects.
FWIW: I also believe that we should stick to PEP 387 and not override it for C API changes. The C extension universe is what makes Python so attractive, so special care must be taken.
By the way, pip hides all compiler output and most developers ignore compiler warnings.
During development the warnings are visible and that's the audience we want to reach. Not the users installing extensions via pip.
There's nothing much we can do if developers ignore those warnings, but at least we have warned them :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Sep 08 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/