This is too-little, too-late (I was offline this past week), but for those who enjoy digging through historical archives, the Tcl folks had an interesting stubs mechanism that was *supposed* to solve the versioning issue (although I suspect it hasn’t actually done much in that regard) in addition to the “cross-platform dynamic linking is a royal pain” (circa 1999) issue: https://wiki.tcl-lang.org/page/Stubs
Basically, you just use a vtable of function pointers exported by version, e.g. Tcl_8_0_Stubs, Tcl_8_1_Stubs, etc. The clients call each function via a layer of indirection, Tcl_8_0_Stubs->Tcl_Tell(), Tcl_8_1_Stubs->Tcl_Tell(), etc.; this is hidden by C macros. (From what I recall of COM, this is a rudimentary implementation of a COM interface.) I’m not sure I would recommend this today -- we were solving different problems back then (CAD workstations from various Unix vendors patched Frankenstein-esque library mismatches), and compiler optimizations weren’t as sophisticated. It had the nice advantage of crashing immediately due to a version mismatch rather than silently corrupting data structures that had undergone changes, etc. Back then, GNU Binutils symbol versioning was just adding to our headaches (again, telling our customers to fix their workstations wasn’t a plausible solution, and it was only on Linux, which was then a very small part of the installed base). > On Oct 1, 2019, at 1:45 AM, Victor Stinner <vstin...@python.org> wrote: > > Sorry for the bad timing. I dislike working under pressure. The > discussion on python-dev, the bug tracker and pull requests was really > interesting. > > The issue has been fixed: the whole idea of stable ABI for PyConfig > has been abandoned. If you want to switch to a different version of > Python when you embed Python, you must recompile your code. It was > always like that and the PEP 587 doesn't change anything. > > PyConfig_InitPythonConfig() and PyConfig_InitIsolatedConfig() > initialize PyConfig to sane default configuration. So if we add new > fields in Python 3.9, you don't have to manually initialize these > fields, except if you explicitly want to use these new fields to > benefit of new configuration options. > > Victor > > Le mar. 1 oct. 2019 à 00:38, Nick Coghlan <ncogh...@gmail.com> a écrit : >> >> >> >> On Tue., 1 Oct. 2019, 6:47 am Victor Stinner, <vstin...@python.org> wrote: >>> >>> Hi back, >>> >>> It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not >>> really liked". >>> >>> I don't see any traction to provide a stable ABI for embedded Python. >>> The consensus is more towards: "it doesn't work and we don't want to >>> bother with false promises" (nor add code for that). >>> >>> Since Lukasz is supposed to tag 3.8.0rc1 today, I propose to remove >>> anything related to "stable API" or "stable ABI" from the PEP 587 >>> right now. I wrote two PRs to remove struct_size: >>> >>> * CPython: https://github.com/python/cpython/pull/16500 >>> * PEP 587: https://github.com/python/peps/pull/1185 >>> >>> Later, if we decide to start proving a stable ABI for embedded Python, >>> we can still add a "version" or "struct_size" field to PyConfig later >>> (for example in Python 3.9). >> >> >> Thanks Victor, I think this is the right way for us to go, given the >> relative timing in the release cycle. >> >> The idea of some day expanding the stable ABI to cover embedding >> applications, not just extension modules, is an intriguing one, but I'm >> genuinely unsure anyone would ever actually use it. >> >> Cheers, >> Nick. >> >> >> >>> >>> Victor >>> _______________________________________________ >>> 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/2JAJQA5OANFPXAJ3327RRPHPQLKVP2EW/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > _______________________________________________ > 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/36RTEPNE6HSPMXGDGSHWDJN56GZRX4YU/ _______________________________________________ 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/U63GT4FYZN7PBG22ZJD522EPYKM3OPQP/ Code of Conduct: http://python.org/psf/codeofconduct/
