> Don't confuse *ABI* and *API* compatibility. For *API* compatibility, it doesn't matter where we put tp_print.

Don't worry, I'm not. (Though I did blur the lines for the sake of a tongue-in-cheek reply to your comment. Probably shouldn't do that in text with people I haven't spent time with in real life :) )

We're not making any progress here, so perhaps it's time to escalate the decision to the steering council. My read of it:

* Python 3.8 removed a deprecated struct member
* Cython prior to 0.29.10 was writing directly to this member to clear it
* any sdists that include pregenerated Cython modules will fail to build against 3.8

Things to decide (beyond this one-off case):
* are deprecated struct members allowed to be removed in new major version?
* should Cython (using non-stable API) be expected to make updates for new major CPython versions?
* should we treat pre-generated Cython .c files with the same compatibility constraints we use for hand-written C code

My view is yes, yes and no.
* If a field has been deprecated for the normal amount of time and is not in the stable API, it can be removed.
* Cython does not use the stable API, and so should expect to make changes when a new major version of CPython is released
* Pre-generated Cython .c files can be easily regenerated, and given their use of low-level and internal APIs would cause undue compatibility burden on CPython if we were to treat everything it uses as public stable API