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?
On 2 June 2018 at 03:45, Jeroen Demeyer <J.Demeyer@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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 02.06.18 05:47, Nick Coghlan wrote:
On 2 June 2018 at 03:45, Jeroen Demeyer <J.Demeyer@ugent.be <mailto:J.Demeyer@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. cheers -- Chris -- Christian Tismer-Sperling :^) tismer@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://pyside.org 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
On 02.06.18 05:47, Nick Coghlan wrote:
On 2 June 2018 at 03:45, Jeroen Demeyer <J.Demeyer@ugent.be <mailto:J.Demeyer@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
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
...
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).
What do you mean? My script does that with all "tp_*" type fields. What else would you want to check? -- Christian Tismer-Sperling :^) tismer@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://pyside.org 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023
On 6/3/2018 10:55 AM, Christian Tismer wrote:
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
...
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).
What do you mean? My script does that with all "tp_*" type fields. What else would you want to check?
I think Ronald is saying we're trying to answer a few questions: 1. Did we accidentally drop anything from the stable ABI? 2. Did we add anything to the stable ABI that we didn't mean to? 3. (and one of mine): Does the stable ABI already contain things that we don't expect it to? Eric
On 3 Jun 2018, at 17:04, Eric V. Smith <eric@trueblade.com> wrote:
On 6/3/2018 10:55 AM, Christian Tismer wrote:
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
...
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). What do you mean? My script does that with all "tp_*" type fields. What else would you want to check?
I think Ronald is saying we're trying to answer a few questions:
1. Did we accidentally drop anything from the stable ABI?
2. Did we add anything to the stable ABI that we didn't mean to?
3. (and one of mine): Does the stable ABI already contain things that we don't expect it to?
That’s correct. There have been instances of the second item over the year, and not all of them have been caught before releases. What doesn’t help for all of these is that the stable ABI documentation says that every documented symbol is part of the stable ABI unless there’s explicit documentation to the contrary. This makes researching if functions are intended to be part of the stable ABI harder. And also: 4. Does the stable ABI actually work? Christian’s script finds cases where exposed names don’t actually work when you try to use them. Ronald
On 4 Jun 2018, at 08:35, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 3 Jun 2018, at 17:04, Eric V. Smith <eric@trueblade.com <mailto:eric@trueblade.com>> wrote:
On 6/3/2018 10:55 AM, Christian Tismer wrote:
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com <mailto:tismer@stackless.com>> wrote:
...
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). What do you mean? My script does that with all "tp_*" type fields. What else would you want to check?
I think Ronald is saying we're trying to answer a few questions:
1. Did we accidentally drop anything from the stable ABI?
2. Did we add anything to the stable ABI that we didn't mean to?
3. (and one of mine): Does the stable ABI already contain things that we don't expect it to?
That’s correct. There have been instances of the second item over the year, and not all of them have been caught before releases. What doesn’t help for all of these is that the stable ABI documentation says that every documented symbol is part of the stable ABI unless there’s explicit documentation to the contrary. This makes researching if functions are intended to be part of the stable ABI harder.
And also:
4. Does the stable ABI actually work?
Christian’s script finds cases where exposed names don’t actually work when you try to use them.
To reply to myself, the gist below is a very crude version of what I was trying to suggest: https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file... <https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file...> The gist is far from usable, but shows some tests that check that symbols in the stable ABI can be used, and tests that everything exported in the stable ABI is actually tested. Again, the code in the gist is a crude hack and I have currently no plans to turn this into something that could be added to the testsuite. Ronald
I've pointed out in bpo-21142 the similar script I added last year to track C globals: https://github.com/python/cpython/tree/master/Tools/c-globals -eric On Mon, Jun 4, 2018 at 1:17 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 4 Jun 2018, at 08:35, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 3 Jun 2018, at 17:04, Eric V. Smith <eric@trueblade.com> wrote:
On 6/3/2018 10:55 AM, Christian Tismer wrote:
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
...
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).
What do you mean? My script does that with all "tp_*" type fields. What else would you want to check?
I think Ronald is saying we're trying to answer a few questions:
1. Did we accidentally drop anything from the stable ABI?
2. Did we add anything to the stable ABI that we didn't mean to?
3. (and one of mine): Does the stable ABI already contain things that we don't expect it to?
That’s correct. There have been instances of the second item over the year, and not all of them have been caught before releases. What doesn’t help for all of these is that the stable ABI documentation says that every documented symbol is part of the stable ABI unless there’s explicit documentation to the contrary. This makes researching if functions are intended to be part of the stable ABI harder.
And also:
4. Does the stable ABI actually work?
Christian’s script finds cases where exposed names don’t actually work when you try to use them.
To reply to myself, the gist below is a very crude version of what I was trying to suggest:
https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file...
The gist is far from usable, but shows some tests that check that symbols in the stable ABI can be used, and tests that everything exported in the stable ABI is actually tested.
Again, the code in the gist is a crude hack and I have currently no plans to turn this into something that could be added to the testsuite.
Ronald
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail...
I know Kushal set up ABI testing for Fedora and has brought up taking the work he did for that and bringing it over to CPython, but I also know he is offline for personal reasons ATM and won't be able to to reply for a little while. On Mon, 4 Jun 2018 at 08:06 Eric Snow <ericsnowcurrently@gmail.com> wrote:
I've pointed out in bpo-21142 the similar script I added last year to track C globals:
https://github.com/python/cpython/tree/master/Tools/c-globals
-eric
On Mon, Jun 4, 2018 at 1:17 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 4 Jun 2018, at 08:35, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 3 Jun 2018, at 17:04, Eric V. Smith <eric@trueblade.com> wrote:
On 6/3/2018 10:55 AM, Christian Tismer wrote:
On 03.06.18 13:18, Ronald Oussoren wrote:
On 3 Jun 2018, at 12:03, Christian Tismer <tismer@stackless.com> wrote:
...
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
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).
What do you mean? My script does that with all "tp_*" type fields. What else would you want to check?
I think Ronald is saying we're trying to answer a few questions:
1. Did we accidentally drop anything from the stable ABI?
2. Did we add anything to the stable ABI that we didn't mean to?
3. (and one of mine): Does the stable ABI already contain things that we don't expect it to?
That’s correct. There have been instances of the second item over the year, and not all of them have been caught before releases. What doesn’t help for all of these is that the stable ABI documentation says that every documented symbol is part of the stable ABI unless there’s explicit documentation to the contrary. This makes researching if functions are intended to be
least part of
the stable ABI harder.
And also:
4. Does the stable ABI actually work?
Christian’s script finds cases where exposed names don’t actually work when you try to use them.
To reply to myself, the gist below is a very crude version of what I was trying to suggest:
https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file...
The gist is far from usable, but shows some tests that check that
the stable ABI can be used, and tests that everything exported in the stable ABI is actually tested.
Again, the code in the gist is a crude hack and I have currently no
symbols in plans to
turn this into something that could be added to the testsuite.
Ronald
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail...
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
participants (7)
-
Brett Cannon -
Christian Tismer -
Eric Snow -
Eric V. Smith -
Jeroen Demeyer -
Nick Coghlan -
Ronald Oussoren