Author scoder
Recipients scoder, vstinner
Date 2020-06-22.22:20:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1592864418.72.0.983145574701.issue41078@roundup.psfhosted.org>
In-reply-to
Content
> Also, later, these structures may change to be more efficient.

Tuples? Really?

Ok, quoting PEP-620:
> Members of … PyTupleObject structures have not changed since the "Initial revision" commit (1990)

I honestly think the reason for that might simply be that there's not so much to improve for tuples.

> nothing prevents a C extension to get or set directly
> PyTupleObject.ob_item[0] (the first item of a tuple).

I certainly understand that that is a problem, especially if "PyObject" may change in the future. And this is essentially what the current "PyTuple_GET_ITEM()" macro does in a binary module.

Should we also turn "_PyTuple_ITEMS()" into a public inline function then to make up for the loss of the "&PyTuple_GET_ITEM(t, 0)" pattern? It would make it explicit what is intended. I think that should be our main goal in the CPython side.
History
Date User Action Args
2020-06-22 22:20:18scodersetrecipients: + scoder, vstinner
2020-06-22 22:20:18scodersetmessageid: <1592864418.72.0.983145574701.issue41078@roundup.psfhosted.org>
2020-06-22 22:20:18scoderlinkissue41078 messages
2020-06-22 22:20:18scodercreate