On Mon, 30 Sep 2019 at 23:50, Victor Stinner <vstin...@python.org> wrote: > > Le lun. 30 sept. 2019 à 13:45, Nick Coghlan <ncogh...@gmail.com> a écrit : > > > I understand that your main motivation to use the Python version > > > number rather than sizeof(PyConfig) is the error message. > > > > No, my main motivation is to create an API that can emit a useful > > error message on *ALL* version conflicts between an embedding > > application and the embedded runtime, not just version conflicts > > involving versions that change the size of the config structs. > > > > The latter option is a good one if all we want to version is the > > struct itself, but I don't think that's what we really want here: I > > think we want to version check the entire API/ABI. > > IMHO this discussion is going too far away from the PEP 587 goals. The > PEP 587 is unrelated to the stable API or the stable ABI.
I would be entirely happy with reverting to PEP 587 as originally accepted (no public struct_size field, no hidden struct versioning field), rather than making last minute changes to it right before the first release candidate. PyConfig and PyPreConfig aren't covered by the stable ABI, so there's no current need for them to be able to evolve gracefully across ABI version bumps. If we *do* decide to evolve them in a direction that allows for more explicit ABI version checks, then doing that as a separate PyVersionedConfig and PyVersionedPreConfig API would have the virtue of keeping the simple case simple, while offering a slightly more awkward to use, but also more forward compatible API for the benefits of folks that wanted to use it. However, *if* we were to add a versioning scheme for 3.8.0rc1, then https://github.com/python/cpython/pull/16496/files covers what I think it should look like (a header_version field that gets set to PY_VERSION_HEX by the embedding application). The only outcome I'd consider undesirable is shipping a public API that's more awkward to use than it needs to be, doesn't conform to the accepted version of the PEP, and doesn't protect against most of the potential sources of segfaults arising from an ABI mismatch (and could even cause them if the supplied "struct_size" value were to be trusted directly, rather than being treated as a lookup value into a set of known-valid struct sizes. The currently checked in code at least doesn't do that, but that's only because it ignores the new struct_size field entirely when making the memset() calls to initialise the config structs). > I suggest to develop a new use case and a new solution to handle this > case. The solution can be *very different* than "compare two versions > at startup". > > For example, we may need a CI to ensure that we don't break the stable ABI: > https://pythoncapi.readthedocs.io/stable_abi.html#check-for-abi-changes > > Another solution is to write a completely new C API from scratch. For > example, HPy ("PyHandle") project proposes to write a new API > implemented on top of the existing API: > https://github.com/pyhandle/hpy > > This project is even developed outside CPython. So the solution can be > found *outside* CPython as well. These are far outside the bounds of "Don't segfault when an embedding application tries to do something that's obviously broken", which I consider the only reason to even consider changing the public API away from what was accepted in PEP 587 in the 3.8rc1 time frame. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/UXRKYP3YCAY2K2GD3QLCGZGQ45WMKORZ/
