why is _PyBytes_Join not public but PyUnicode_Join is?
We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why? PyUnicode_Join is. Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all. -gps
On 31/08/2012 02:43, Gregory P. Smith wrote:
We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why?
PyUnicode_Join is.
Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all.
For what it's worth, I could also make use of it in the regex module. I use PyUnicode_Join when working with Unicode strings, but I could also use PyBytes_Join if it were available instead of having to look it up.
Am 31.08.12 03:43, schrieb Gregory P. Smith:
We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why?
API minimalism. No API should be public unless somebody can demonstrate an actual use case. The Unicode API of Python 2.0 had a serious mistake in making dozens of functions public in the API. This broke twice in Python's history: once when UCS-4 became supported, and again for PEP 393. For the former, a work-around was possible by introducing macros, to support API compatibility while breaking ABI compatibility. For PEP 393, huge efforts were necessary to even preserve the API (and this only worked with limitations). So by default, all new functions should be internal API (static if possible), until somebody has explicitly considered use cases and considered what kind of stability can be guaranteed for the API.
Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all.
It's not really that difficult. Instead of r = PyBytes_Join(sep, x); you write r = PyObject_CallMethod(sep, "join", "O", x); This is just a few more letters to type. Or are you concerned with the runtime overhead that this causes? Don't be: the cost of actually joining is much higher than the cost of making the call. Regards, Martin
On Fri, Aug 31, 2012 at 8:24 PM, "Martin v. Löwis"
So by default, all new functions should be internal API (static if possible), until somebody has explicitly considered use cases and considered what kind of stability can be guaranteed for the API.
The other aspect we're conscious of these days is that folks like the IronClad and cpyext developers *are* making a concerted effort to emulate the full C API of CPython-the-runtime, not just implementing Python-the-language. External tools like Dave Malcolm's static analyser for gcc also need to be taught the refcounting semantics of any new API additions. So, unless there's a compelling reason for direct public access from C, the preferred option is to only expose the corresponding Python API via the general purpose APIs for calling back into Python from C extensions. This minimises the induced workload on other groups, as well as making future maintenance easier for CPython itself. New additions are still possible - they're just not the default any more. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Aug 31, 2012 at 3:43 AM, Gregory P. Smith
We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why?
PyUnicode_Join is.
Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all.
I wondered about the same thing a month ago - http://mail.python.org/pipermail/python-dev/2012-July/121031.html Eli
participants (5)
-
"Martin v. Löwis" -
Eli Bendersky -
Gregory P. Smith -
MRAB -
Nick Coghlan