This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author benjamin.peterson
Recipients Arfrever, belopolsky, benjamin.peterson, eric.smith, ezio.melotti, pitrou, rhettinger
Date 2010-07-07.20:19:00
SpamBayes Score 0.00766653
Marked as misclassified No
Message-id <>
In-reply-to <>
2010/7/7 Alexander Belopolsky <>:
> Alexander Belopolsky <> added the comment:
> This is definitely the right way to do it.  I expect that I will have only minor nit-picks as I go through the patch.
> 1. You can probably just do
> #define PyStructSequence_SET_ITEM PyTuple_SET_ITEM
> #define PyStructSequence_GET_ITEM PyTuple_GET_ITEM
> there is no need to repeat the argument lists.

I think the preprocessor requires this. (Anyway it fails without.)

> 2. I am comparing PyStructSequence_New and PyTuple_New:
>  - PyStructSequence_New does not fill ob_item array with NULLs.

I'm not sure it really matters, since the fields should always be
filled in, but I suppose it can't hurt...

>  - PyStructSequence_New does not call _PyObject_GC_TRACK
> I believe tp_free gets inherited, so structseq tp_new should follow what tuple's tp_new does.  I am not 100% sure on the second point, though _PyObject_GC_TRACK may be redundant after PyObject_GC_NewVar.

This is only needed when doing freelist magic in tupleobject.c.

> 3. In structseq_repr, do you need PyTuple_GetItem?  I think you can get away with PyTuple_GET_ITEM, or better PyStructSequence_GET_ITEM.

Yeah, that's fine.
Date User Action Args
2010-07-07 20:19:01benjamin.petersonsetrecipients: + benjamin.peterson, rhettinger, belopolsky, pitrou, eric.smith, ezio.melotti, Arfrever
2010-07-07 20:19:00benjamin.petersonlinkissue8413 messages
2010-07-07 20:19:00benjamin.petersoncreate