> On 9 Jun 2021, at 12:28, Inada Naoki <songofaca...@gmail.com> wrote: > > I think stable ABI keeps symbols, signatures, and memory layouts. > I don't think stable ABI keeps all behaviors.
As often “it depends”. Behaviour is IMHO part of the API/ABI contract. That said, that does not necessarily mean that we cannot change behaviour at all, but that the cost to users for such changes should be taken into account. > > For example, Py_CompileString() is stable ABI. > When we add `async` keyword, Py_CompileString() starts raising an > Error for source code using `async` name. > Is it ABI change? I don't think so. I agree. But its not as easy as “it is not an ABI change because it only changes functionality of a function”. The interface contract of Py_CompileString is that it compiles Python code. If the rules for what valid Python code is change (such as the introduction of ‘async’ as a hard keyword) the function can start to reject input that was accepted earlier. That’s IMHO different from a change to Py_CompileString that starts raising an error unconditionally because we no longer want to expose the API. > > I want to drop Py_UNICODE support in Python 3.12. It is another > incompatible change in PyArg_Parse*() *API*. > Users can not use "u" format after it. It is an incompatible *API* > change, but not an *ABI* change. It is an ABI change: an extensions targetting the stable ABI no longer works due to a change in implementation. That doesn’t necessarily mean the change cannot be made, especially when a deprecation warning is emitted before the feature is removed. > > I suspect we had made many incompatible *API* changes in stable ABIs already. > > If I am wrong, can we stop keeping stable ABI at Python 3.12? > Python 4.0 won't come in foreseeable future. Stable ABI blocks Python > evolution. The annoying part of the stable ABI is that it still exposes some implementation details and behaviour that make it harder to write correct code (such as borrowed references, these can be very convenient but are also easy to misuse). That’s one reason why HPy is an interesting project, even when only targeting CPython. And to be clear: I’m not opposed to the change for the “#” format character and the removal of the “u” format you mention earlier. Ronald > > Regards, > -- > Inada Naoki <songofaca...@gmail.com> — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
_______________________________________________ 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/AGTHK7XIS6OPS5H6Z2ZA3XWHILJ4R4OZ/ Code of Conduct: http://python.org/psf/codeofconduct/
