[issue4385] Py_Object_HEAD_INIT in Py3k

2009-05-23 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: Unless I'm missing something it looks like this can be closed as fixed. -- nosy: +r.david.murray resolution: - fixed stage: commit review - committed/rejected status: open - pending ___ Python

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-05-23 Thread Georg Brandl
Changes by Georg Brandl ge...@python.org: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4385 ___ ___ Python-bugs-list

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-04-27 Thread Georg Brandl
Georg Brandl ge...@python.org added the comment: Actually, seeing that other macro docs do that as well, I'm okay with it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4385 ___

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-04-25 Thread Jeroen Ruigrok van der Werven
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment: 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

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-04-25 Thread Jeroen Ruigrok van der Werven
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment: 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. -- stage: needs patch - commit review

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-04-25 Thread Georg Brandl
Georg Brandl ge...@python.org added the comment: Isn't listing the expansion literally a bit fragile? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4385 ___

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-04-25 Thread Jeroen Ruigrok van der Werven
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment: 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

[issue4385] Py_Object_HEAD_INIT in Py3k

2009-03-30 Thread Daniel Stutzbach
Changes by Daniel Stutzbach dan...@stutzbachenterprises.com: -- versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4385 ___ ___

[issue4385] Py_Object_HEAD_INIT in Py3k

2008-11-30 Thread Barry A. Warsaw
Barry A. Warsaw [EMAIL PROTECTED] added the comment: 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. -- nosy: +barry priority: release blocker - critical

[issue4385] Py_Object_HEAD_INIT in Py3k

2008-11-28 Thread Marc-Andre Lemburg
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: 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).

[issue4385] Py_Object_HEAD_INIT in Py3k

2008-11-22 Thread Martin v. Löwis
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't think PyObject_HEAD_INIT should be removed. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4385 ___

[issue4385] Py_Object_HEAD_INIT in Py3k

2008-11-21 Thread Nick Coghlan
New submission from Nick Coghlan [EMAIL PROTECTED]: 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