This is an implementation of the Py_SETREF and Py_XSETREF macros
proposed in http://mail.python.org/pipermail/python-dev/2008-May/079862.html

As an example, I added a few conversions among the extension modules.

FWIW, I also wanted to propose for Py_INCREF(op) to evaluate as (op), so
that it can be used as return or assignment value, e.g.:
    return Py_INCREF(result);
or:
    self->var = Py_INCREF(obj);

but it's perhaps a bit more controversial.

Benjamin, the patch is against py3k, also it might also apply cleanly on
trunk...

Sorry for the confusion. It seems to me this sort of thing would be
useful in 2.6, too, so I marked it.

A comment on the patch:

Since object.h may be included from C++ extensions, you should not use a 
C++ keyword "new" as a variable name.

This new patch avoids using temporary variables named "new", it also
adopts the "do { ... } while (0)" idiom for definition of the macros.

-1 on the new macros.  The mnemonic doesn't work for me and the example 
code fragments are to my eyes less readable than before.  These add to 
the learning curve for reading and writing C extensions and provide 
nearly zero benefits.  

Assigning from an INCREF feels weird.  It is somewhat at odds with our 
coding style where we tend to stick with dirt simple C, trying to put 
operations on different lines rather than combining too many step in a 
single line.

Le samedi 28 juin 2008 à 20:12 +0000, Raymond Hettinger a écrit :
> Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
> 
> -1 on the new macros.  The mnemonic doesn't work for me and the example 
> code fragments are to my eyes less readable than before.  These add to 
> the learning curve for reading and writing C extensions and provide 
> nearly zero benefits.  

They might not be ideal, but I think they can be helpful to avoid
writing incorrect code out of laziness. There is already Py_CLEAR with
similar purposes.

> Assigning from an INCREF feels weird.  It is somewhat at odds with our 
> coding style where we tend to stick with dirt simple C, trying to put 
> operations on different lines rather than combining too many step in a 
> single line.

Ok.

Just to note, I proposed similar macro on the mailing list under the
name Py_ASSIGN.

The name suggests a different behavior to me - I assumed it would set the reference count to a specific value.  Maybe this is the kind of thing Raymond had in mind when he said "The mnemonic doesn't work for me".

Py_ASSIGN could be a better name, but given the enthusiasm generated by this proposal, I think we might just as well close the issue.

I agree with Raymond about the Py_INCREF.  I could see more uses for this macro without the Py_INCREF, especially for things like in-place arithmetic operations.  The following pattern appears a lot in code like Objects/longobject.c:

Old code:

/* add one to x */
temp = PyNumber_Add(x, one);
Py_DECREF(x);
x = temp;
if (x == NULL)
    return NULL;


With a non-INCREF version of Py_SETREF:

/* add one to x */
Py_SETREF(x, PyNumber_Add(x, one));
if (x == NULL)
    return NULL;