On 18. 05. 21 17:17, Marc-Andre Lemburg wrote:
On 18.05.2021 17:07, Petr Viktorin wrote:
On 18. 05. 21 16:14, Nick Coghlan wrote:
On Wed, 19 May 2021, 12:00 am Ronald Oussoren via capi-sig, <capi-sig@python.org <mailto:capi-sig@python.org>> wrote:
> On 18 May 2021, at 15:08, Petr Viktorin <encukou@gmail.com <mailto:encukou@gmail.com>> wrote: > > > > On 18. 05. 21 14:20, Marc-Andre Lemburg wrote:
>> Right, but if you want to use the stable ABI, the compiler would not see >> the needed Py_FrozenMain() definition to link against -- if you remove it >> from the stable ABI. >> So overall, it's probably not such a good idea to remove that >> particular API from the stable ABI list. > > Yeah, the more I dig, the more I'm convinced that Py_FrozenMain should be on the list. > > That means it should always be available, though -- even in static builds.
I don’t understand why this is so. Py_FrozenMain must only be present in the dynamic library, including the stable ABI on Windows (because AFAIK it already is). In a staticly linked python executable the symbol is not necessary because it will (and can) never be used.
It's an edge case in the stable ABI guarantees - a module that uses the stable ABI should work from a statically linked Python, even if it does something odd like report the address of a symbol that isn't useful in a statically linked Python.
Yes.
But -- this might not be possible on Windows. To use Py_FrozenMain on Windows, you need to provide definitions for the functions PyWinFreeze_ExeInit, PyWinFreeze_ExeTerm and PyInitFrozenExtensions.
Argh, researching this is turning up so many dead ends. Back to the beginning:
Py_FrozenMain was only added to python3dll.c in Python 3.10, in GH-23730. Adding it actually looks like an afterthought: IMO, adding an undocumented function to the stable ABI should be discussed a bit more, especially if it's as weird as this one. Victor, do you have any details here?
No one is using Py_FrozenMain with the stable ABI on Windows (unless they're testing 3.10). I doubt anyone needs it *in the Stable ABI* on other platforms either.
To reply to Marc-Andre's earlier question:
Removing the export will break such applications. Removing the API from the stable ABI makes it impossible to use the stable ABI from such applications.
Is that intended ? Perhaps I'm missing something.
Given that it was added in 3.10, removing it won't be a regression.
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. 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.