For now http://docs.python.org/3/extending/newtypes.html#supporting-cyclic-garbage-c... at first the doc demonstrate long way than note Py_CLEAR and Py_VISIT macroses.
I like to remove code similar to
if (self->first) { vret = visit(self->first, arg); if (vret != 0) return vret; }
and
tmp = self->first; self->first = NULL; Py_XDECREF(tmp);
and replace those to Py_VISIT and Py_CLEAN.
I think we have to demonstrate best practices in our examples. Let's py2.7 branch live untouched, change only docs for python 3.x
Any objections?
-- Thanks, Andrew Svetlov
2013/2/9 Andrew Svetlov andrew.svetlov@gmail.com:
For now http://docs.python.org/3/extending/newtypes.html#supporting-cyclic-garbage-c... at first the doc demonstrate long way than note Py_CLEAR and Py_VISIT macroses.
I like to remove code similar to
if (self->first) { vret = visit(self->first, arg); if (vret != 0) return vret; }and
tmp = self->first; self->first = NULL; Py_XDECREF(tmp);and replace those to Py_VISIT and Py_CLEAN.
I think we have to demonstrate best practices in our examples. Let's py2.7 branch live untouched, change only docs for python 3.x
Any objections?
IMO, it's fine if you change 2.7, too.
On Sat, Feb 9, 2013 at 11:52 PM, Andrew Svetlov andrew.svetlov@gmail.com wrote:
I think we have to demonstrate best practices in our examples. Let's py2.7 branch live untouched, change only docs for python 3.x
Any objections?
For debugging purposes, I think extension developers do need to understand what those macros are doing under the covers. However, the order of presentation should definitely be reversed to "here is how you should write it", followed by an explanation of what that actually means with the macros expanded.
For Py_CLEAR, it would be OK to just link to the macro's entry in the C API docs, but for Py_VISIT, I think it's worth expanding out the full example.
Cheers, Nick.
-
Andrew Svetlov -
Benjamin Peterson -
Nick Coghlan