Steve Dower <steve.do...@python.org> added the comment:
> 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37250> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
