classification
Title: Py_Object_HEAD_INIT in Py3k
Type: behavior Stage: resolved
Components: Documentation, Interpreter Core Versions: Python 3.0, Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: asmodai, barry, georg.brandl, lemburg, loewis, ncoghlan, r.david.murray
Priority: critical Keywords:

Created on 2008-11-21 23:43 by ncoghlan, last changed 2009-05-23 16:55 by georg.brandl. This issue is now closed.

Messages (10)
msg76224 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2008-11-21 23:43
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
msg76252 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-11-22 16:51
I don't think PyObject_HEAD_INIT should be removed.
msg76542 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-11-28 17:41
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).
msg76657 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2008-11-30 19:44
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.
msg86483 - (view) Author: Jeroen Ruigrok van der Werven (asmodai) * (Python committer) Date: 2009-04-25 12:00
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.
msg86499 - (view) Author: Jeroen Ruigrok van der Werven (asmodai) * (Python committer) Date: 2009-04-25 12:54
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.
msg86519 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-04-25 14:57
Isn't listing the expansion literally a bit fragile?
msg86522 - (view) Author: Jeroen Ruigrok van der Werven (asmodai) * (Python committer) Date: 2009-04-25 15:00
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.
msg86689 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-04-27 17:11
Actually, seeing that other macro docs do that as well, I'm okay with it.
msg88236 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-05-23 14:22
Unless I'm missing something it looks like this can be closed as fixed.
History
Date User Action Args
2009-05-23 16:55:29georg.brandlsetstatus: pending -> closed
2009-05-23 14:22:33r.david.murraysetstatus: open -> pending

nosy: + r.david.murray
messages: + msg88236

resolution: fixed
stage: commit review -> resolved
2009-04-27 17:11:42georg.brandlsetmessages: + msg86689
2009-04-25 15:00:59asmodaisetmessages: + msg86522
2009-04-25 14:57:54georg.brandlsetmessages: + msg86519
2009-04-25 12:54:18asmodaisetmessages: + msg86499
stage: needs patch -> commit review
2009-04-25 12:00:53asmodaisetnosy: + asmodai
messages: + msg86483
2009-03-30 18:19:05stutzbachsetversions: + Python 3.1
2008-11-30 19:44:13barrysetpriority: release blocker -> critical
nosy: + barry
messages: + msg76657
2008-11-28 17:41:50lemburgsetnosy: + georg.brandl, lemburg
messages: + msg76542
components: + Documentation
assignee: georg.brandl
2008-11-22 16:51:42loewissetnosy: + loewis
messages: + msg76252
2008-11-21 23:43:56ncoghlancreate