[Python-Dev] RE: test_sort.py failure

[Tim Peters]

[Raymond Hettinger]
...
> If we want to insist on the ob_allocated invariants, then

I want to insist on *documented* invariants, but I don't particularly
care what they are.  Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either).  Indeed, that's how list.sort() got broken here
to begin with:  you failed to divine the undocumented invariant it
relied on, and so you managed to break that invariant.  It's really
not surprising!

The idea that "list.ob_item == NULL implies list.allocated may be
lying" is at least as obscure as the invariant that broke, and if it's
intended but not documented it will be implicated in future bugs. 
There's no force working toward keeping knowledge of list.allocated
confined to the two routines you originally taught about it, unless we
believe listobject.c will never be changed again <wink>.

> * list_ass_slice() should add a line to maintain them,
> * list_resize() can drop the test for ob_item != NULL, and
> * tp_new needs a custom list_new() establishing the invariants.

I don't know about the first two, but I don't know why the last would
be needed:  list.allocated starts life at 0 now for the same reason
list.ob_item starts life as NULL now:  PyType_GenericNew guarantees to
zero-fill all the data space (there's nothing special about
list.ob_item in this respect -- the generic new has no idea there's a
pointer in the struct, it simply zeroes out everything).  That
establishes the currently documented invariants.