On 16.12.15 16:53, Random832 wrote:
At the risk of bikeshedding, this needs do { ... } while(0), or
it almost certainly will eventually be called incorrectly in an
if/else statement. Yes, it's ugly, but that's part of the cost
of using macros.
Yes, of course, and the patch for issue20440 uses this idiom. Here it is
omitted for clearness.
If it were implemented as below, then it could evaluate ptr only
once at the cost of requiring it to refer to an addressable
pointer object:
PyObject **__tmpp__ == &(ptr);
PyObject *__tmp__ = *__tmpp__;
*__tmpp__ = (new_value);
PY_DECREF(__tmp__);
I'm not entirely sure of the benefit of a macro over an inline
function.
Because the first argument is passed by reference (as in Py_INCREF etc).
Or why it doesn't INCREF the new value, maintaining
the invariant that ptr is an owned reference.
Because in the majority of using cases stealing a reference is what is
needed. Otherwise we would virtually always need to decref a reference
just after using this macro. And couldn't use it as Py_XXX(obj->attr,
PySomething_New()).
I think "SET" names imply that it's safe if the original
reference is NULL. This isn't an objection to the names, but if
it is given one of those names I think it should use Py_XDECREF.
Originally I proposed pairs of functions with and withot X in the name
(as Py_DECREF/Py_XDECREF). In this poll this detail is omitted for
clearness. Later we can create a new poll if needed.
_______________________________________________
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
