Py_SIZE is not useful

[encukou]

The meaning of a type's Py_SIZE (ob_size) depends entirely on the type. The interpreter generally sets it on allocation, but can't rely on the value afterwards.

• Py_SIZE is not different from other instance data and doesn't really need special treatment
• The interpreter doesn't know the size of a PyVarObject instance

[markshannon]

I would say that it is worse than not useful, it is a trap.
For example, PyLongObject. The "size" has never been the actual size, due to the sign, and it is even less so in 3.12.

[vstinner]

Are there better existing APIs with a well defined behavior?

Py_SIZE() has flaws but can be used correctly if you know the type and so what the result means. If it's bad, we need a migration path.

[encukou]

APIs for what?
For a general-purpose field on an instance, yes.
For allocating variable-sized instances, yes.

There's nothing to read the size of a variable-sized instance in general. That could be useful (but might not be cheap to store).
If we don't add that: if you need it for a type you control, you can reserve a field for it and let tp_new set it. And you can define a getter for it.
If it's not a type you control and there's no getter... you probably shouldn't be looking at its memory, so why ask how big it is.

[iritkatriel]

Is this issue then simply "let's deprecate Py_SIZE"?

[encukou]

That a possible solution.
But we should only deprecate Py_SIZE after we add/document the preferred replacement. What will that be? That depends on whether we end up adding a reliable way to tell the size.