Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2021-04-27.14:17:45.393>created_at=<Date2021-04-16.14:48:28.426>labels= ['expert-C-API', '3.10', 'OS-windows']
title='Remove PyOS_ReadlineFunctionPointer from the stable ABI list'updated_at=<Date2021-04-27.14:17:45.393>user='https://github.com/encukou'
The inclusion of PyOS_ReadlineFunctionPointer in python3dll.c (*) was a mistake. According to PEP-384:
functions expecting FILE* are not part of the ABI, to avoid depending on a specific version of the Microsoft C runtime DLL on Windows.
The situation may have changed and it might be reasonable to revisit this decision, but that would call for a larger discussion. There are FILE*-taking functions that are probably much ore useful than this one. (But, I think it's a good idea to limit the stable ABI to file-like Python objects anyway.)
I see PEP-384 as being definitive (where it's not ambiguous). The python3dll.c list and public/private headers do not actually define the stable ABI.
So, I'd like to remove the function from the list.
PyOS_ReadlineFunctionPointer has a bad API. I fixed recently PyOS_StdioReadline because it used the Python C API without holding the GIL. To acquire the GIL, you need to access a *private* _PyOS_ReadlineTState variable which is kind of unfortunate :-(
bpo-40826: Fix GIL usage in PyOS_Readline() (GH-20579)
Fix GIL usage in PyOS_Readline(): lock the GIL to set an exception.
Pass tstate to my_fgets() and _PyOS_WindowsConsoleReadline(). Cleanup
bpo-40826: Add _PyOS_InterruptOccurred(tstate) function (GH-20599)
my_fgets() now calls _PyOS_InterruptOccurred(tstate) to check for
pending signals, rather calling PyOS_InterruptOccurred().
my_fgets() is called with the GIL released, whereas
PyOS_InterruptOccurred() must be called with the GIL held.
test_repl: use text=True and avoid SuppressCrashReport in
Fix my_fgets() on Windows: fgets(fp) does crash if fileno(fp) is closed.