GeezerVison

@tacaswell: In one of your PR, you wrote "typ" instead of "type". Was it a deliberate typo? Is there an issue in C++? Should I rename the variable to "new_type"?

Oops, my question is on the second parameter of Py_SET_TYPE() :-)

I built Py_SET_TYPE() macro with g++ and Python 3.8: I don't have any warning or error. "type" sounds like a valid parameter type.

I am not sure, that code come from @eric-wieser via numpy/numpy#16417 (comment)

This macro doesn't behave the same way as the function in 3.9. I think a more accurate macro would be:

which can be used as part of an expression like the function version of Py_SET_TYPE can:

return Py_SET_TYPE(my_obj, some_type), my_obj;

is legal in 3.9 and with my macro, but illegal with this PR.

Oh wow, the C language is so surprising sometimes :-) I designed Py_SET_SIZE() as a static inline function to ensure that the result is void and to prevent strange usage. But I didn't know that return Py_SET_TYPE(my_obj, some_type), (...); was legit.

I updated macros to use , (void)0. According to https://stackoverflow.com/a/25021889 this syntax is endorsed by the C standard, since NDEBUG uses #define assert(ignore) ((void)0).

Thanks for finding some precedent. I've seen "always use parens and do { } while(0);" given as macro advice forever, but I don't remember ever seeing this case before.

In the meanwhile, I created the backport compatiblity header file :-) It defines a static inline function which returns void:
https://github.com/pythoncapi/pythoncapi_compat/blob/219cdd858595fb5d478117b0ef4758fedc3d2365/pythoncapi_compat.h#L29

Maybe tomorrow when it will be more mature (than 1 hour old), numpy might want to use it.