I have a C extension that uses PyList_Check. Sometimes
the pointer being checked is not a real Python object,
so ob->ob_type might be NULL. Under Python 2.1 and
early, this simple macro would handle this case without
problems. Under Python 2.2, this case will cause Python
to segfault.

This occurs because PyList_Check under Python 2.2 has
changed and includes PyType_IsSubtype which assumes
that both of its arguments are Python type objects. If
this is not the case, then all hell can break loose,
which in my case happens when the first argument is a
NULL pointer.

My use of PyList_Check may not be good programming, but
this change in PyList_Check and other such object
checks has radically changed the behavior of these
macros. In Python 2.1 and early, they were simply
pointer comparisons: it was that object or it wasn't.
Now these pointers must be Python objects for these
macros to work. Otherwise Python is likely to crash.

I can change my code and probably should, but this
issue should be considered in some detail because of
its wide ramifications on Python extension programming.
This change really begs for a Pointer Object in Python
which wraps a C pointer.

Logged In: YES 
user_id=31435

Sorry, your code was never legitimate.  If you got away with 
passing non-object pointers to PyList_Check before, all 
that says is that the HW you were running on didn't happen 
to raise bus errors for trying to read up an op->ob_type 
pointer where it didn't exist.  IOW, PyList_Check was 
never "simply a pointer comparison":  it always first had to 
*read up* a pointer-aligned value at an offset *from* the 
argument pointer.  I suppose you're running on Intel boxes, 
where misaligned reads aren't fatal.

Note too that PyList_Check is documented as requiring a 
PyObject* argument.

Logged In: YES 
user_id=6380

I agree with Tim -- such code was never legal. An object 
whose ob_type field is NULL is not an object, and you can't 
expect the PyXXX_Check() macros to work for these.