04.12.19 18:54, Skip Montanaro пише:

...

...

I don't think stable code which uses macros should be changed (though I see the INCREF/DECREF macros just call private inline functions, so some conversion has clearly been done). Still, in new code, shouldn't the use of macros for more than trivial use cases (constant defs, simple one-liners) be discouraged at this point?

You can't goto from the inline function.

Thanks, that is true, and if needed would add another case where macros are preferred over inline functions (as would use of the cpp token pasting operator, ##). I see relatively few goto-using macros spread across a number of source files, but the examples I highlighted in Python/ast_opt.c use return, not goto. It seems they could easily be crafted as inline functions which return 0 (forcing early return from enclosing function) or 1 (equivalent to current fall through).

In this case it is the same as a goto. Both affect the control flow of the caller. In these files (symtable.c, compile.c, ast_opt.c, etc) there are sequences of calls for child nodes. Every call can return an error, so you need to check every call and return an error immediately after the call. With inline functions you would need to write if (!VISIT(...)) { return 0; } if (!VISIT(...)) { return 0; } if (!VISIT(...)) { return 0; } instead of just VISIT(...); VISIT(...); VISIT(...); This will increase the number of lines by two or three (according to the current PEP 7 recommendations) times. This will add a lot of boilerplate which distracts the attention from the logic. It will need to pass all arguments explicitly (macros allow to pass some arguments implicitly). This will add a lot of spots for introducing errors. If you will need to change some details, for example decrement state->recursion_depth before return you will need to change handreds lines instead of few sites (and guess how much bugs you will introduce). Macros exist to get rid of the boilerplate. They are used not only in private files, this idiom is used in the public API. See the Py_VISIT macro. It passes implicit arguments and returns from the caller.

04.12.19 22:12, Skip Montanaro пише:

This is my last post on this, at least as far as specific usage instances are concerned. See my question about PEP 7 below. If that is a discussion people think worthwhile, please start a new thread.

...

if (!VISIT(...)) { return 0; } if (!VISIT(...)) { return 0; } if (!VISIT(...)) { return 0; }

instead of just

VISIT(...); VISIT(...); VISIT(...);

That seems easily solved with the VISIT-as-macro calling _VISIT-as-inline function.

I do not understant what problem do you want to solve. VISIT() in symtable.c is: #define VISIT(ST, TYPE, V) \ if (!symtable_visit_ ## TYPE((ST), (V))) \ VISIT_QUIT((ST), 0); It literally calls other (non-inlined) function, check its result and returns from the caller function (in VISIT_QUIT). I do not understand how inline function can help here.

In any case, I was just somewhat surprised to see relatively new code using macros where it seemed inline functions would have worked as well or better.

In these cases macros cannot be replaced by inline functions because inline function do not have access to variables of the caller and cannot affect the control flow of the caller. The new code follows idioms used in the old code. There are also many other cases where macros save as from duplicating code and cannot be replaced with inline functions (C++ exceptions, templates, constructors and constant expressions could replace macros in some cases, but CPython is implemented on pure C, not even using all features of the recent standard). Don't afraid macros, they are the part of the language and pretty safe if use them properly.