On 27 Dec 2016, at 20:04, Serhiy Storchaka wrote:

From the documentation:

https://docs.python.org/3/c-api/stable.html

In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."

But they don't.

I prepared a sample patch that adds the notes to Unicode Objects and Codecs C API (http://bugs.python.org/issue29086). I'm going to add them to all C API.

What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?

A directive would make it easier to ensure that the text about the stable API is consistent. I’d also consider adding that directive to all API’s that *are* part of the stable API instead of the other way around (that would also require changes to …/stable.html). That would have two advantages: firstly it makes it easier to document from which version an API is part of the stable ABI, and secondly forgetting the annotation would imply that an API is not part of the stable ABI instead of accidentally claiming to increase the stable ABI. Ronald

On 28Dec2016 1145, Brett Cannon wrote:

On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren mailto:ronaldoussoren@mac.com> wrote: A directive would make it easier to ensure that the text about the stable API is consistent. I’d also consider adding that directive to all API’s that *are* part of the stable API instead of the other way around (that would also require changes to …/stable.html). That would have two advantages: firstly it makes it easier to document from which version an API is part of the stable ABI, and secondly forgetting the annotation would imply that an API is not part of the stable ABI instead of accidentally claiming to increase the stable ABI.

I like Ronald's suggestion of both using a directive and making it for the stable ABI since it should be an opt-in thing for the API to be stable instead of opt-out.

The directive is a good idea, but I'm a little concerned about the stable API being opt-out in the headers and opt-in in the documentation. Perhaps we should also figure out the preprocessor gymnastics we need to make it opt-in in the headers too? Though once we get the build validation to detect when the stable API changes accidentally it'll be less of an issue. Cheers, Steve

On 30 Dec 2016, at 15:33, Nick Coghlan wrote:

On 29 December 2016 at 06:41, Steve Dower mailto:steve.dower@python.org> wrote: On 28Dec2016 1145, Brett Cannon wrote: On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren mailto:ronaldoussoren@mac.com mailto:ronaldoussoren@mac.com>> wrote: A directive would make it easier to ensure that the text about the stable API is consistent. I’d also consider adding that directive to all API’s that *are* part of the stable API instead of the other way around (that would also require changes to …/stable.html). That would have two advantages: firstly it makes it easier to document from which version an API is part of the stable ABI, and secondly forgetting the annotation would imply that an API is not part of the stable ABI instead of accidentally claiming to increase the stable ABI.

I like Ronald's suggestion of both using a directive and making it for the stable ABI since it should be an opt-in thing for the API to be stable instead of opt-out.

The directive is a good idea, but I'm a little concerned about the stable API being opt-out in the headers and opt-in in the documentation.

Perhaps we should also figure out the preprocessor gymnastics we need to make it opt-in in the headers too? Though once we get the build validation to detect when the stable API changes accidentally it'll be less of an issue.

Making it opt-in in the documentation could make the build validation easier: check the list from the *docs* against the actual symbols being exported by the headers.

That would have a few benefits:

- if you accidentally add a new function to the stable ABI, you get a test failure - if you deliberately add a new function to the stable ABI, but forget to document it as such, you get a test failure - if the stable ABI version added directive in the docs doesn't match the stable ABI version used in the headers, you get a test failure

(That suggests the tests would need to check the headers with all stable ABI versions from 3.2 up to the current release and ensure they match the current C API documentation)

This is probably a lot easier than trying to coax the headers into defining symbols as not part of the stable API by default (“opt-in”), especially when trying to do so in a portable way. With GCC and clang it seems to be possible to use function attributes to force compile time errors when using functions not in the limited API, but that wouldn’t work for other declarations (struct definitions, …) and still is error prone. Ronald

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com mailto:ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com