> it appears that an old, poorly verified bug report 

Why do you say the bug report is poorly verified? The libffi maintainers accept it is an issue.

https://github.com/libffi/libffi/issues/33

> inspired a change that was actually not well tested and so incorrectly broke valid code without deprecation. Trying to be as polite as possible, this appears to indicate a poor testing process, if not a poor understanding of the actual code in question.

Well, the original developer of ctypes is no longer involved in maintaining it. Those of us who try to address ctypes issues are perhaps not as well-versed in the code as the original developer and maintainer, but we do our best. This of course applies to other areas in CPython, and many other projects besides.

The change was accompanied by tests, which have been no doubt found wanting, but do *you* write software which guarantees no bugs ever in released versions? Using your example above, I will look into what was missed and try to improve the checking. The underlying libffi issue is a real one. The change wasn't introduced in a cavalier manner, as you seem to be suggesting.

> I strongly encourage you and other Python devs to carefully assess what went wrong here and to work out (and write down) what will be done going forward to avoid such problems. Simply rolling this change back and saying "sorry, but we're overworked volunteers and stuff happens" is not going to regain lost trust. In fact, it's pretty close to a promise that this sort of issue will happen again. I think that you may want to make sure that it is not the take-away message here.
Sorry if that sounds in any way unappreciative.  Thanks.

Well, "stuff happens" is true, and I don't mean to trivialise anything. But almost all released non-trivial software has bugs. If we didn't have a good process, then we could perhaps be held to task, but that's not the case. That things sometimes slip through the cracks is pretty much a given in software development - not confined to CPython.

My backporting the changes to 3.8 and 3.7 were premature, and I have learned that lesson. It's often a matter of judgement, and sometimes that can go wrong.

Do you regularly test your code with Python alpha and beta versions? I ask because I may reinstate the check for Python 3.9 after seeing what false-positive cases were missed here. Python 3.9 is at alpha 2 level right now. Continued feedback could help to minimise the chances of future surprises.