The memory layout of PyType object's changes in Py3k from the
*compiler's* point of view. This means PyObject_HEAD_INIT can no longer
be used to initialise PyVarObject type definitions.

However, the documentation doesn't point this out (or document
PyVarObject_HEAD_INIT at all), and the compiler warnings currently
generated are not clear. Suggestion is to remove PyObject_HEAD_INIT from
Py3k entirely so this becomes a compile error instead of a warning, and
then better document the situation so extension authors know how to
correctly initialise the affected C structs.

See mailing list thread at:
http://mail.python.org/pipermail/python-3000/2008-November/015241.html

I don't think PyObject_HEAD_INIT should be removed.

I think this is a documentation bug more than anything else.

Removing PyObject_HEAD_INIT() is certainly not an option, since it is
required to init static PyObject singletons that are declared in C (just
like the PyTypeObjects are).

I agree with MvL and MAL.  We can't change Python, so this is a
documentation issue.  I'm lowering the priority so it doesn't block the
release.

I added initial documentation for both PyObject_HEAD_INIT and
PyVarObject_HEAD_INIT in r71874.

The text currently reads:

PyObject_HEAD_INIT(type)¶

    This is a macro which expands to initialization values for a new
PyObject type. This macro expands to:

    _PyObject_EXTRA_INIT
    1, type,

PyVarObject_HEAD_INIT(type, size)¶

    This is a macro which expands to initialization values for a new
PyVarObject type, including the ob_size field. This macro expands to:

    _PyObject_EXTRA_INIT
    1, type, size,

Of course my internals knowledge is little compared to you guys, so any
feedback to improve this is appreciated.

Just to make it clear: I committed this to trunk, since it is relevant
to that as well. We can always move the documentation over with minor
tweaks.

Isn't listing the expansion literally a bit fragile?

Mmm, depends on the case, I guess. The current implementation of the
macros is hardcoded for the most part. Where it is variable I left the
arguments in.

I was following the example from the other macros and I guess that since
this is the typical object initialization call it would make sense to
show what the default fills in.

I welcome opinions on this.

Actually, seeing that other macro docs do that as well, I'm okay with it.

Unless I'm missing something it looks like this can be closed as fixed.