[Python-Dev] Stable ABI

[Ronald Oussoren]

> On 3 Jun 2018, at 12:03, Christian Tismer <tismer at stackless.com> wrote:
> 
> On 02.06.18 05:47, Nick Coghlan wrote:
>> On 2 June 2018 at 03:45, Jeroen Demeyer <J.Demeyer at ugent.be
>> <mailto:J.Demeyer at ugent.be>> wrote:
>> 
>>    On 2018-06-01 17:18, Nathaniel Smith wrote:
>> 
>>        Unfortunately, very few people use the stable ABI currently, so it's
>>        easy for things like this to get missed.
>> 
>> 
>>    So there are no tests for the stable ABI in Python?
>> 
>> 
>> Unfortunately not.
>> 
>> https://bugs.python.org/issue21142 is an old issue suggesting automating
>> those checks (so we don't inadvertently add or remove symbols for
>> previously published stable ABI definitions), but it's not yet made it
>> to the state of being sufficiently well automated that it can be a
>> release checklist item in PEP 101.
>> 
>> Cheers,
>> Nick.
> 
> Actually, I think we don't need such a test any more, or we
> could use this one as a heuristic test:
> 
> I have written a script that scans all relevant header files
> and analyses all sections which are reachable in the limited API
> context.
> All macros that don't begin with an underscore which contain
> a "->tp_" string are the locations which will break.
> 
> I found exactly 7 locations where this is the case.
> 
> My PR will contain the 7 fixes plus the analysis script
> to go into tools. Preparind that in the evening.

Having tests would still be nice to detect changes to the stable ABI when they are made. 

Writing those tests is quite some work though, especially if those at least smoke test the limited ABI by compiling snippets the use all symbols that should be exposed by the limited ABI. Writing those tests should be fairly simple for someone that knows how to write C extensions, but is some work.

Writing a tests that complain when the headers expose symbols that shouldn’t be exposed is harder, due to the need to parse headers (either by hacking something together using regular expressions, or by using tools like gccxml or clang’s C API).  

BTW. The problem with the tool in issue 21142 is that this looks at the symbols exposed by lib python on linux, and that exposed more symbols than just the limited ABI. 
 
Ronald