On 18. 05. 21 18:23, Marc-Andre Lemburg 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.
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 ?
Py_FrozenMain:
- is not documented
- was untested until yesterday (thanks to Victor!)
- is not present in all builds of Python
I'm all for fixing that and adding it to the stable ABI, but I think it's too late for Python 3.10. Let's add it in 3.11?
Should the stable ABI be driven by "I need this to work" or rather "anything which doesn't expose internals is fine" ?
"Anything which doesn't expose internals is fine" is a better goal; more comprehensive guidelines are here: https://devguide.python.org/c-api/#guidelines-for-changing-the-limited-api
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.
Well, that nicely illustrates the general state of the stable ABI now. (Though I don't yet know much about how a capsule-based API will interact with the stable ABI.)
But for in 3.10 I'm want to define what the stable ABI *is*, so it can be meaningfully improved later.