> Rejected Ideas > ============== > > It might be good to add a similar tier in the Python (not C) API, > e.g. for ``types.CodeType``. > However, the opt-in mechanism would need to be different (if any). > This is outside the scope of the PEP.
For types.CodeType constructor, would it be possible to just a mention in the *documentation* that this API is "unstable"? It would come with a link to definition of the "unstable" C API: explain that it can change in 3.x.y bugfix releases, not not in 3.x.0 releases (major? minor? I never recall how they should be called). For now, I don't think that there is a need to actively remove this API from the "default" Python API and add an opt-in option to get access to these functions. But having a mention just in the documentation would be better than nothing. It seems to be popular complain and request. For example, most of the ast module would fall into this "unstable API". Previous discussions: * Proposal: declare "unstable APIs" https://mail.python.org/archives/list/[email protected]/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/ * Making code object APIs unstable https://mail.python.org/archives/list/[email protected]/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/ On one side, it's important to communicate that the API *can* change in 3.x.0 releases, but also provide some warranties that the API *must not change* in 3.x.y bugfix releases. Victor _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/AS7KUFPSGNRNBUKMXPHHKHXAVDAZH2AT/ Code of Conduct: http://python.org/psf/codeofconduct/
