New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make documentation about macros in C API explicit about rvalue vs statement #61789
Comments
CPython API "functions" implemented as macros can expand into either As of this writing Py_INCREF works as an rvalue. But discussion on I propose that the documentation make an explicit ruling on whether Note: I added you three (Georg, Mark, Martin) as I thought you might |
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. |
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 to CPython core. But arguably writers of extension types may want to mutate the size field of a varsize object. |
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. |
There are some extension modules (pytables) that do Oh, and Cython:
#define __Pyx_PyBool_FromLong(b) ((b) ? (Py_INCREF(Py_True), Py_True) : (Py_INCREF(Py_False), Py_False)) |
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. |
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 Py_RETURN_NONE's implementation to multiple statements, probably with the do { ... } while(0) trick, so it worked again. I'd be shocked if that change broke any existing code. So that's no big deal. Having external code that depends on Py_INCREF being an rvalue is my concern, and what I hoped you'd bring up on bug bpo-17206. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: