The patch below solves problem in cases like: 
 
if(something) 
    PyDECREF(xxx) 
else 
    dosomethingelse(); 
 
(Patch against Python 2.4) 

Logged In: YES 
user_id=31435

What problem?  It's intended that you put a semicolon 
following Py_DECREF() invocations, and if you do I don't see 
any problem here.

The "do ... while(0)" trick isn't optimized away by all 
compilers, so it's not without cost.  Because Py_DECREF 
appears a *lot* in the source code, I don't want its 
expansion to introduce needless overheads.

Logged In: YES 
user_id=80475

Sorry, I concur with Tim.

The "problem" has not not proven to be a real world issue in
the many years that Python has been in the wild.

For some compilers, there is a cost to the "solution". 

Logged In: YES 
user_id=31435

I wanted to hear what "the problem" was first <wink>.  If, 
e.g., it's some overly helpful compiler complaining about a 
non-existing (in reality) ambiguity about if/else pairing, then 
sticking the "if" part in a block (delimit it with curly braces) 
should shut it up.

Logged In: YES 
user_id=621175

OK, sorry - the original problem really was a rather confusing warning 
for the statement 
 
if(something) Py_DECREF(xxx); 
 
The compiler warned about an ambiguous "else", so I had to dig into 
the Python sources to understand the problem. 
 
Constructing the case above I mixed something up and thought there 
might be an even bigger problem, which is, of course, not the case. 
 
So: it falls back to just a potential obscure warning compared to some 
potential overhead. Obviously you prefer the obscure warning... 
 

Logged In: YES 
user_id=31435

Na, we don't like obscure warnings, and in fact the project 
has a "no warnings, period" policy on the major compilers (gcc 
and MS).  Whichever compiler you're using, I bet the warning 
goes away if you write

if(something) { Py_DECREF(xxx); }

instead.  No warnings + no problems + no overheads is the 
solution we like -- even if that means you have type two 
entire characters <wink> sometimes.