[Python-Dev] RE: [Python-checkins] python/dist/src/Include objimpl.h, 2.58, 2.59 (original) (raw)

Tim Peters tim.peters at gmail.com
Thu Jul 15 04:48:20 CEST 2004

[Jim Fulton]

Documented the new PyVISIT macro to simplify implementation of tptraverse handlers. (Tim made me do it. ;)

[Raymond Hettinger]

That Tim has been tyrant lately ;-)

It's the only way left to get things done .

+ /* Utility macro to help write tptraverse functions */ _+ #define PyVISIT(op) _ _+ do { _ _+ if (op) { _ _+ int vret = visit((op), arg); _ _+ if (vret) _ _+ return vret; _ _+ } _ + } while (0)

I tried out this macro with the itertools module and found that it did a nice job of compacting boilerplate code.

One thought jumped out though. The macro assumes that the enclosing function has consistent with the use of the variable names "visit" and "arg": static int islicetraverse(isliceobject *lz, visitproc visit, void *arg) { PyVISIT(lz->it); return 0; } If the parameters are named something else ("vfunc" for example), MSVC++6.0 complains: C:\py24\Modules\itertoolsmodule.c(1118) : warning C4013: 'visit' undefined; assuming extern returning int Don't know if it is worth it, but you could safeguard the macro by including visit and arg in the parameter list.

-1. Instead it should be documented that the tp_traverse implementation must name its arguments "visit" and "arg" if it wants to use this macro. Since tp_traverse implementations can look so relentlessy the same, it's a Positive Good to encourage them to look relentlessly the same. I want the process of writing a correct tp_traverse implementation to be mindlessly simple, and likewise I want the process of reviewing one to be as simple as asking "did it apply VISIT to each member and then return 0?". Rigid uniformity helps both goals -- and as there's no creative joy to be had in trying to write a clever tp_traverse either, deviation from a rigid template would just be gratuitous deviation.

principled-perversion-is-a-different-story-ly y'rs - tim

More information about the Python-Dev mailing list