On 9 November 2017 at 22:35, Antoine Pitrou <solip...@pitrou.net> wrote: > On Thu, 9 Nov 2017 04:22:20 -0800 > Raymond Hettinger <raymond.hettin...@gmail.com> wrote: >> >> Probably, we're the wrong people to be talking about this. The proposal is >> to make these macros part of the official API so that it starts to appear in >> source code everywhere. The question isn't whether the above makes sense to >> you and me; instead, it is whether other people can make heads or tails out >> the above examples. > > Generally I would advocate anyone wanting to write a third-party C > extension, but not very familiar with the C API and its quirks, use > Cython instead. I'm not sure if that's an argument for the SETREF APIs > to remain private or to become public :-)
I'm with Antoine on this - we should be pushing folks writing extension modules towards code generators like Cython, cffi, SWIG, and SIP, support libraries like Boost::Python, or safer languages like Rust (which can then be wrapped with cffi), rather than encouraging more bespoke C/C++ extensions modules with handcrafted refcount management. There's a reason the only parts of https://packaging.python.org/guides/packaging-binary-extensions/ that have actually been filled in are the ones explaining how to use a tool to write the extension module for you :) For me, that translates to being -1 on making these part of the public API - for code outside CPython, our message should consistently be "Do not roll your own refcount management, get a code generator or library to handle it for you". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
