This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients asvetlov, gregory.p.smith, jcea, loewis, mark.dickinson, meador.inge, serhiy.storchaka, skrah
Date 2012-07-26.20:46:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5011AC97.7010602@v.loewis.de>
In-reply-to <201207262327.10259.storchaka@gmail.com>
Content
> 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.
History
Date User Action Args
2012-07-26 20:46:17loewissetrecipients: + loewis, gregory.p.smith, jcea, mark.dickinson, asvetlov, skrah, meador.inge, serhiy.storchaka
2012-07-26 20:46:17loewislinkissue15402 messages
2012-07-26 20:46:16loewiscreate