Thanks, that's useful! There are 3 other instances of this in the multiarray sources, so it's probably best to change them all to the macro so no others will learn from bad examples ;-)

OK, actually none of the others is called with PyExc_DeprecationWarning... In fact the present case specifies a stacklevel of 0 rather than 1, so it's not exactly equivalent to DEPRECATE(msg) (nor the PyErr_Warn() case) either. Not sure if that's an issue - it's not clear to me what a stacklevel of 0 means in this case.

FWIW that stuff wasn't entirely clear to me either when I wrote it. I figured stack level 0 was what you would want, because the C function call doesn't count as a stack level, so going deeper would just be throwing away useful information.

Meaning, I guess, e.g. this warning
/lib/python2.4/site-packages/numpy/core/records.py:157: DeprecationWarning: DType strings 'O4' and 'O8' are deprecated because they are platform specific. Use 'O' instead dtype = sb.dtype(formats, aligned)
would be raised from within the dtype code instead of records.py - the above with stack level 1 also seems sensible enough to me, though.

Yeah, that message looks fine to me.

I'll go ahead then and use DEPRECATE().

I agree, it does (silly attempt to save a variable).

That's the compiler's job ;)

I moved the trailing comment down a line, removed a trailing space, and squashed the commits together before committing as 5cb956e. Thanks for the fix.