On Wed, 17 Jun 2020 at 12:27, Victor Stinner <vstin...@python.org> wrote:
> > If PEP 387 (Backwards Compatibility Policy) is accepted, all the > > incompatible changes changes will require a two-year deprecation period. > > Right? > [...] > > So far, it doesn't seem to be a giant disaster :-) Only a few C > extensions had to be modified, and only a few lines. For example, the > l-value change only required to modify exactly 5 lines in the whole > numpy project! Personally, I'm completely fine with the C API changes. But it does seem to me that it exposes a flaw (or maybe just over-simplification) in PEP 387, as I don't see how to reconcile the approach you took (and the arguments you make here) with the wording of the PEP. Unless you make fairly free use of the "if in doubt, ask the SC" clause - and I suspect Victor has a somewhat above average instinct as to the SC's views on such matters ;-)) My concern here is that PEP 387 could become a blocker for proposals by people who are not "in the know" as to how to confirm if something's backward incompatible. It would maybe be good if these changes could be incorporated into that PEP as a case study in how the new process would have applied. I'll link this message into the PEP 387 discussion, to close the loop. Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZQ33UCSUNFJOGHUREA6DFFIWMFQZZZ2B/ Code of Conduct: http://python.org/psf/codeofconduct/
