Jeffrey Yasskin wrote: > Yes, that's my intention. (Well, not the annoying part, but making > them use Py_IncRef instead for ABI compatibility is, I think, a good > thing.) If they don't want ABI compatibility, they shouldn't ask for > it. Giving them something else useful to ask for is why I mentioned an > API compatibility mode. > > To decrease the annoyance of having to change source code, we could > have Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode.
Forcing developers to choose between the speed of the INCREF/DECREF macros and the proposed ABI compatibility mode for the benefit of an as yet hypothetical GIL-less CPython API implementation seems more like a way to kill adoption of the ABI compatibility mode rather than a way to encourage the use of the IncRef/Decref functions. The idea of allow an extension to explicitly version the stable ABI they're using with a macro like Py_ABI_VERSION is a good one though. I'd suggest using the Python version in hex (e.g. 0x020700 and 0x030200) rather than an ISO date though. That way an extension developer that wanted to ensure there code worked with a particular Python version and later could just define the right Py_ABI_VERSION rather than have to specifically compile against that earliest version. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
