On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum <gu...@python.org> wrote: > In the not so distant past I have proposed to introduce a new category, > "Unstable APIs". These are public but are not guaranteed to be backwards > compatible in feature releases (though I feel they should remain so in bugfix > releases). > > I'm not sure whether those should have a leading underscore or not. Perhaps > (like some other languages do and like maybe we've used in a few places) the > name could just include the word "Unstable"?
I recall discussions about PyCode_New(). IMO this API should not be public at all. It leaks way too many implementation details: cell variables, optimization for bytecode offset to line and column numbers, exception table, etc. This API changed often and will continue to change. It's not the right abstraction level. We just exposed the function because it was technically possible and it was convenient since Python consumes its own C API. The internal C API was created to draw a line between what API can be consumed outside Python (public) and what API must not be used outside Python (internal) unless you're writing a debugger or other uncommon very specific use case. The main difference is the warranties provided (public) or not (internal) by Python: tests, documentation, backward compatibility. In Python, sadly the types.CodeType type also has a public constructor and many projects break at each Python release because the API changes. Hopefully, it seems like the new CodeType.replace() method added to Python 3.8 mitigated the issue. IMO CodeType.replace() is a better abstraction and closer to what developers need in practice. I'm not convinced that advertising an API as being Unstable (in the documentation?) is going to solve any kind of problem. People love to use private APIs, and they do it simply because it's technically possible :-) At the end of the day, we have to help them updating their code, otherwise we (at least my Red Hat team) cannot update Python. I designed the internal C API to be more annoying to be used (need to define a macro, need more specific #include) in the hope that people will think twice before using it :-) Victor _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YCHLFQ5KW6XF5C5CFWF4MRTZEXVBZBMA/ Code of Conduct: http://python.org/psf/codeofconduct/
