Stefan Behnel <stefan...@behnel.de> added the comment:

Victor asked me for a review, so, well, what should I say? The intention seems 
right, and the patch also looks good to me.

>From the top of my head, I wouldn't know any problems this would produce with 
>Cython specifically, although it's worth testing. If we find anything, then 
>it's hopefully easy to adapt to in a point release, which Cython users can 
>then build their code with to support Py3.8+. That's the way it usually works 
>with Cython.

The main problem I see is that while this change may crash in some cases (the 
lucky cases that are easy to detect), it will leak references in others, which 
can be really difficult to detect. My own biased little gut feeling still wants 
me to believe that the impact of this could be somewhat low. Why? Well, how 
many heap-allocated types with a custom "tp_dealloc()" do you expect there to 
be? My feeling is that most existing code still uses statically allocated types 
for that. CPython has a couple of examples (that the PR adapts), but IIRC, 
that's mostly because some core devs wanted to test-ride parts of the newer 
type creation C-API in the standard library (a perfectly valid reason, but that 
also makes it a bad example). From the little valley that I sit in, I don't see 
a large bunch of other usages of that API out in the wild. That doesn't mean 
they are not there, and there might well be some large projects that could be 
bitten by this change. But I'm sure it's not the majority.

So, on the one hand, any breaking change to the C-API may make users end up 
with little maintained projects that they depend on and that break in Py3.y and 
later without anyone having access to the PyPI project account to push a fix 
release. Very annoying situation.

On the other hand, a breaking C-API change is not the only problematic case, 
and people have to deal with similar situations anyway. CPython changes are 
really just one of many, many ways to render your code unusable.

I would suggest clear, open communication of this. It's solving a bug. It makes 
CPython safer. It's not difficult to adapt your code, once you know it's 
affected. The usual PY_VERSION_HEX guard will do it for you. I think we should 
risk it.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to