Benjamin Peterson <benja...@python.org> added the comment: 2010/7/7 Alexander Belopolsky <rep...@bugs.python.org>: > > Alexander Belopolsky <belopol...@users.sourceforge.net> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8413> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
