Hi Stefan, Le lun. 19 nov. 2018 à 13:18, Stefan Krah <stefan at bytereef.org> a écrit : > 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, Oh, I never used this function. These functions are private (name prefixed by "_") and excluded from the limited API. For me, the limited API should be functions available on all Python implementations. Does it make sense to provide PyFloat_Pack4() in MicroPython, Jython, IronPython and PyPy? Or is it something more specific to CPython? I don't know the answer. If yes, open an issue to propose to make this function public? > I need PyUnicode_KIND() IMHO this one should not be part of the public API. The only usage would be to micro-optimize, but such API is very specific to one Python implementation. For example, PyPy doesn't use "compact string" but UTF-8 internally. If you use PyUnicode_KIND(), your code becomes incompatible with PyPy. What is your use case? I would prefer to expose the "_PyUnicodeWriter" API than PyUnicode_KIND(). > need PyUnicode_AsUTF8AndSize(), Again, that's a micro-optimization and it's very specific to CPython: result cached in the "immutable" str object. I don't want to put it in a public API. PyUnicode_AsUTF8String() is better since it doesn't require an internal cache. > I *wish* there were PyUnicode_AsAsciiAndSize(). PyUnicode_AsASCIIString() looks good to me. Sadly, it doesn't return the length, but usually the length is not needed. Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4