Experiment an opt-in new C API for Python? (leave current API unchanged)
Victor Stinner wrote:
Moreover, I failed to find anyone who can explain me how the C API is used in the wild, which functions are important or not, what is the C API, etc.
In practice people desperately *have* to use whatever is there, including functions with underscores that are not even officially in the C-API. I have to use _PyFloat_Pack* in order to be compatible with CPython, I need PySlice_Unpack() etc., I need PyUnicode_KIND(), need PyUnicode_AsUTF8AndSize(), I *wish* there were PyUnicode_AsAsciiAndSize(). In general, in daily use of the C-API I wish it were *larger* and not smaller. I often want functions that return C instead of Python values ot functions that take C instead of Python values. The ideal situation for me would be a lower layer library, say libcpython.a that has all those functions like _PyFloat_Pack*. It would be an enormous amount of work though, especially since the status quo kind of works. Stefan Krah
participants (9)
-
Antoine Pitrou
-
Benjamin Peterson
-
Glenn Linderman
-
Jeff Allen
-
Matěj Cepl
-
Nathaniel Smith
-
Petr Viktorin
-
Stefan Krah
-
Victor Stinner