[Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is? (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Fri Aug 31 15:20:15 CEST 2012
- Previous message: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
- Next message: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Aug 31, 2012 at 8:24 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
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 at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
- Next message: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]