On 19.05.2021 10:00, Nick Coghlan wrote:
On Wed, 19 May 2021, 2:23 am Marc-Andre Lemburg, <mal@egenix.com <mailto:mal@egenix.com>> wrote:
On 18.05.2021 17:27, Petr Viktorin wrote: >>> I'm definitely not proposing to remove Py_FrozenMain from the default, >>> minor-version-specific ABI. >> >> I don't quite follow that logic. Not many people are using the >> stable ABI, that's clear, but that should be seen as a chance, >> not as proof that APIs are not used and thus not necessary. >> >> If you're saying: "frozen applications should not use the stable >> ABI" that's fine, but it should be documented as such. > > If you need something that's not part of the stable ABI yet, then you can't use > it. That goes for any part of the stable ABI. Exactly, which is why it should include a good set of the APIs to make it useful.Applications that embed or statically link Python (including frozen applications) gain nothing from using the stable ABI. Only extension modules benefit, since they can be built once and imported from multiple versions.
That's one perspective, but not necessarily one which has much benefit these days, since it fairly easy to recompile modules against new Python versions.
The other, and I believe, much more important perspective is stability in the API. APIs not included in the stable ABI do not get the benefit of being stable for the rest of the major version editions of Python, so using them can potentially incur additional maintenance overhead and breakage going forward.
As such, the stable ABI is important for both extension modules and applications.
Py_FrozenMain() has been around for more then 2 decades by now and unchanged, so it's probably one of the more stable APIs we have :-)
Of course, if you want to frame the stable ABI in a different way that's reasonable as well.
What I'd like to learn is what the criteria of that framing would look like, because so far, the stable ABI is a list of APIs that Martin von Löwis started a while back, without a clear indication of why APIs should be in the stable ABI or why not.
As it stands right now, it's a fairly high level API definition, which goes into depth only in particular areas, but leaves out important other ones, with seemingly no justification.
E.g. why is the low level capsule API included, but not the capsule definitions of the datetime module ?
IMO, a lot more APIs would have to be added to make the stable API useful for more than the handful of extensions / applications using it at the moment.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 19 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.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 https://www.egenix.com/company/contact/ https://www.malemburg.com/