On 19.12.2018 12:18, Nick Coghlan wrote:
On Tue, 18 Dec 2018 at 22:34, M.-A. Lemburg <mal@egenix.com> wrote:
Hi Viktor,
please do consider the fact that the "Limited ABI" has essentially failed to meet expectations. It's hardly used and not really needed anymore.
This simply isn't true - the last time this was asserted, the SIP developers pointed out that PyQT binary extensions rely on the stable ABI to maintain compatibility across Python 3 versions, with only SIP itself needing to be recompiled each release.
Remember that we don't hear from happy users of a feature - we only hear from users for whom the feature is incomplete.
I did not say that it isn't used, but the effort it takes to maintain it and keep it working does not match up to the few gains it has for a few extension writers.
If you search for "Py_LIMITED_API" on Google, you get less then 4000 hits. Many of those are related to issues with the limited API, e.g.
https://bitbucket.org/cffi/cffi/issues/350/issue-with-py_limited_api-on-wind...
If you search for '"#define Py_LIMITED_API"' you get around 100 hits.
It is not a widely used feature of the Python C API.
The main reason for the limited ABI was the desire to have extensions work without recompilation on system where access to compilers was difficult, mainly Windows at the time.
Err, no - it was so that folks didn't have to ship umpteen quadrillion versions of their binary extensions to support users on multiple different versions of Python.
Nope. Please see PEP 384 regarding the original motivation back in 2009:
https://www.python.org/dev/peps/pep-0384/
""" On Linux, changes to the ABI are often not much of a problem: the system will provide a default Python installation, and many extension modules are already provided pre-compiled for that version. If additional modules are needed, or additional Python versions, users can typically compile them themselves on the system, resulting in modules that use the right ABI.
On Windows, multiple simultaneous installations of different Python versions are common, and extension modules are compiled by their authors, not by end users. To reduce the risk of ABI incompatibilities, Python currently introduces a new DLL name pythonXY.dll for each feature release, whether or not ABI incompatibilities actually exist. """
As mentioned the situation has changed since then, so it is possible for users to compile extensions on Windows as well. Additionally, the number of needed binaries has gone down a lot, since we no longer have UCS2/UCS4 builds and most Windows systems run 64-bit now. So things have gotten easier for extension writers as well.
You are also forgetting that using the limited ABI significantly limits your possibilities as an extension writer to use APIs from the CPython API. It does work for simple extensions or ones which only do basic operations such as providing call level APIs (sip, cffi, go bridges).
Even SIP ships with pre-compiled versions for each Python release:
https://pypi.org/project/SIP/#files
and so does cffi:
https://pypi.org/project/cffi/#files
SIP also doesn't use the limited ABI per default; it only supports using it. cffi at least tries to use it where possible.
It turns out that CPython's habit of embedding version numbers in filesystem paths causes additional problems in that regard, and the long life of Python 2.7 meant that folks were needing to build for at least Py2 and Py3 anyway, and hence the opportunity for simplification offered by the stable ABI was limited in practice.
I've been building binaries for several systems and several of my extensions for years, but never found it attractive to have limitations in APIs in return for perhaps being able to leave out a few compiler runs in the release process (most of those ran in parallel anyway, so were not causing major issues).
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Dec 19 2018)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/