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 scoder
Recipients jdemeyer, ncoghlan, petr.viktorin, scoder, steve.dower, vstinner
Date 2019-06-12.18:48:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> they can equally easily zero out the entire structure and ignore it without changing behavior on any Python 3.x.

Any solution that we apply in Cython will require users to regenerate their .c sources with a new Cython version in order to make it compile in Py3.8. The main decision point in this ticket is: should they need to or not? Everything else is just minor technicalities. (I didn't bring up this topic, but the question is up on the table now.)

> I have no problem changing the names of deprecated/reserved fields in PyTypeObject between releases. Source compatibility guarantees do not extend that far.

Fair enough, and I'm ok with letting CPython move forward cleanly and break things that are easily fixed on user side.

My point is that it makes no sense to justify bpo-37221 with the goal of not breaking Cython modules, when at the same time another change (the one discussed here) has already broken them. Either we find a striking justification for bpo-37221 that *excludes* Cython generated modules, or we take back *both* changes and restore full source code compatibility. Everything in between is just causing useless code churn and annoyance on all sides.
Date User Action Args
2019-06-12 18:48:39scodersetrecipients: + scoder, ncoghlan, vstinner, petr.viktorin, jdemeyer, steve.dower
2019-06-12 18:48:39scodersetmessageid: <>
2019-06-12 18:48:39scoderlinkissue37250 messages
2019-06-12 18:48:38scodercreate