This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients jdemeyer, ncoghlan, petr.viktorin, scoder, steve.dower, vstinner
Date 2019-06-18.22:33:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1560897207.8.0.480714036783.issue37250@roundup.psfhosted.org>
In-reply-to
Content
(Note: this isn't SC feedback yet, it's individual contributor feedback from me)

As others noted, the reason we treat "Incompatible with Cython generated source code" distinctly from other C API source compatibility issues is because Cython-using projects often add the generated files to their source tarballs, so install targets only need a C compiler, not Cython itself. Even when it's a case where the older Cython generated code wasn't doing the right thing, there's pragmatic value in smoothing those transitions.

That said, I still agree with PEP 590's decision to re-use the existing reserve function pointer slot, rather than adding a new one to the end of the type structure indefinitely, which would make the compatibility measure:

1. In 3.8.0b2, move tp_print to the end of the structure (rather than removing it entirely) to make the "type->tp_print" in the old Cython generated code harmless rather than a compilation error
2. In 3.9.0a1, remove it entirely again

That way we still end up in the place we were aiming to get in PEP 590, we just take an extra step in getting there.
History
Date User Action Args
2019-06-18 22:33:27ncoghlansetrecipients: + ncoghlan, scoder, vstinner, petr.viktorin, jdemeyer, steve.dower
2019-06-18 22:33:27ncoghlansetmessageid: <1560897207.8.0.480714036783.issue37250@roundup.psfhosted.org>
2019-06-18 22:33:27ncoghlanlinkissue37250 messages
2019-06-18 22:33:27ncoghlancreate