STINNER Victor <vstin...@python.org> added the comment:
Raymond: > AFAICT, no one has ever has problems with these being macros. This issue is about the API of PyFloat_AS_DOUBLE(). Implementing it as a macro or a static inline function is an implementation detail which doesn't matter. But I don't know how to disallow "PyFloat_AS_DOUBLE(obj) = value" if it is defined as a macro. Have a look at the Facebook "nogil" project which is incompatible with accessing directly the PyObject.ob_refcnt member: "Extensions must use Py_REFCNT and Py_SET_REFCNT instead of directly accessing reference count fields" https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit Raymond: > You could simply document, "don't do that". Documentation doesn't work. Developers easily fall into traps when it's possible to fall. See bpo-30459 for such trap with PyList_SET_ITEM() and PyCell_SET() macros. They were misused by two Python projects. Raymond: > We really don't have to go on thin ice converting to functions that might or > might not be inlined depending on compiler specific nuances. Do you have a concrete example where a static inline function is not inlined, whereas it was inlined when it was a macro? So far, I'm not aware of any performance issue like that. There were attempts to use __attribute__((always_inline)) (Py_ALWAYS_INLINE), but so far, using it was not a clear win. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45476> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
