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.
It would certainly be good to make the Stable ABI complete, but that'll take time. In 3.10 are we finally adding a rigid definition of what the stable ABI even is :)
The missing piece can be added later, but if we add it now, removing it would be much harder.
Didn't we just provide proof that this particular API is needed ? Why add it later ?
I never was a great fan of the stable ABI, but now do see a point since we're moving towards a new HPy based API.
The stable ABI could provide a path forward to have a basic set of APIs defined which can be made to work with HPy initially and then later extended further.
However, for this to work out, we'd have to have a better definition of what is supposed to go into the stable ABI. The PEPs don't provide much guidance on this and this discussion also doesn't clarify this.
Yes, the Py_FrozenMain() API is not used by many applications, but it is essential for a subset of applications. Is that good enough ?
Should the stable ABI be driven by "I need this to work" or rather "anything which doesn't expose internals is fine" ?
To give you an example:
When I wrote mxODBC, the database interface for Python in 1997, I found that Python was missing native object types for handling date/time values.
So I created mxDateTime, which exposes a C API for creating and working with date/time values. This became a standard for many years, until Python grew its own datetime module -- also exposing a C API.
Now, the stable ABI does not include this datetime C API, so for my purposes, it's not usable.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 18 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/