On 15 Jun 2020, at 15:44, M.-A. Lemburg mal@egenix.com wrote:
On 15.06.2020 14:36, Petr Viktorin wrote:
On 2020-06-15 13:47, M.-A. Lemburg wrote:
On 15.06.2020 12:53, Matti Picus wrote:
The fact that extension writers turn to APIs marked as internal is usually triggered by lack of public APIs for the purpose. This should be a signal to consider making an API public or creating a better interface to provide similar logic.
Unfortunately, this doesn't really work as a signal, because nothing is actually signalled back to CPython devs ā until the private API in question stops working.
True, there's a feedback loop missing for such situations. Perhaps we should create one (this C API ML already serves in part as such a feedback loop).
The feedback loop is already there: the issue tracker and various mailing lists. This is an undocumented, private API which should be a clear indication that 3th-party developers are not supposed to use it.
FWIW: I don't see problems for other implementations to provide the above API, but perhaps I'm missing something.
I see no documentation on what the function should do. I assume providing a function with unspecified semantics is always a problem.
See above. Being unspecific is intentional, as long as the pre- and post-conditions are made clear in the docs.
The unspecified part is that there are no documented pre- and post-conditions ;-).
For this particular API Iām far from convinced that exposing it (and another private API used by the OP) is necessary.
Ronald
ā Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/