[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Change by STINNER Victor : -- components: +C API ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Larry Hastings added the comment: Oh, and, yes, it's true that Py_RETURN_NONE currently takes advantage of Py_INCREF being an rvalue, and changing Py_INCREF to a statement would break the existing implementation. But Py_RETURN_NONE itself is of necessity a statement. We would simply change

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Larry Hastings added the comment: Amaury: I'd appreciate it if you'd bring those examples up on bug 17206. If we're going to change the semantics of Py_INCREF I'd prefer we did it with our eyes wide open. -- ___ Python tracker

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Amaury Forgeot d'Arc added the comment: There are some extension modules (pytables) that do return Py_INREF(x), x; and Py_RETURN_NONE is also defined with a comma expression. Oh, and Cython: #define __Pyx_PyBool_FromLong(b) ((b) ? (Py_INCREF(Py_True), Py_True) : (Py_INCREF(Py_False), Py_False

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Larry Hastings added the comment: > Py_INCREF usable as an rvalue sounds more like an accident > than a deliberate feature I'd go with "misfeature", but in no way is it accidental. The coding deliberately preserves the rvalue-ness of it, c.f. _Py_REF_DEBUG_COMMA. -- _

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Antoine Pitrou added the comment: Py_INCREF usable as an rvalue sounds more like an accident than a deliberate feature, and it would be IMO counter-productive to codify this behaviour in the docs. As for the lvalue usage of Py_REFCNT and Py_SIZE, I think it would be better if it were limited

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

Georg Brandl added the comment: There are also some macros usable as lvalues, such as Py_REFCNT or Py_SIZE (they aren't documented at all currently). Anyway, documenting as statement-only unless explicitly stated differently is fine with me. -- ___

[issue17589] Make documentation about macros in C API explicit about rvalue vs statement

New submission from Larry Hastings: CPython API "functions" implemented as macros can expand into either rvalues or statements. Most expand into statements (often using the do {} while (0) syntactic sugar trick), but occasionally they're legal as rvalues. As of this writing Py_INCREF works as a