> That would defeat the purpose of the test. We want to test whether
> __sizeof__ is correct, so we shouldn't use __sizeof__ in the test to
> compute the expected result. I understand that object.__sizeof__ is
> actually a different implementation, but still: there might be errors e.g.
> in the type definition that cancel out errors in the sizeof
> implementation. The more "directly" the expected result is computed, the
> better.

I do not think that the purpose of testing is a testing of object.__sizeof__. 
Memory consumption consists of two parts -- memory for C structure (and the 
base object implementation works for this) and extra memory, for which we 
write a specialized __sizeof__ method. If we doubt object.__sizeof__, then we 
are obligated to implement and test __sizeof__ methods for all C-implemented 
classes, not using the base object implementation.

> I also realize that such tests will be fragile if the the structures
> change. This is a good thing, IMO: anybody changing the layout of some
> object should *have* to verify that the size computation is still correct,
> so it's good that the test breaks if the structures change.

Such tests is too fragile. They force the programmer to write unnecessary code 
in cases when it can be done automatically. We write in C code 
sizeof(SomeStruct), and not the sum of sizes (+paddings) of the structure 
fields.

Let's focus on the differences, on the extra memory usage that not allows us to 
simply use inherited base object implementation.