homepage

> All such cases are bugs (memory manager works with tp_basicsize and 
> tp_itemsize, not with __sizeof__ result) and tests do not test it. In 
> paranoidal mode we should tests both __sizeof__ and object.__sizeof__. For all 
> classes, even for those that do not use the extra memory. I think it is really 
> tedious.
It's clearly a tradeoff. The question is whether a more paranoid
formulation of the test might detect any real bugs. issue15456
efficiently demonstrates that the current style can detect bugs
which testing with object.__sizeof__ can't. This is not theoretical:
it's an *actual* bug that did get detected with the current style
of testing, but would not have been detected with object.__sizeof__.
This, IMO, makes the more tedious formulation worthwhile.
Of course, developers need to be educated how to deal with any
breakage of these tests: it may be that they really just added
or removed fields to the structure, in which case they just need
to update the struct specs. In many cases, I claim, addition of
new fields (in particular of struct type "P") corresponds to the
allocation of additional memory blocks.