[Python-Dev] RE: test_sort.py failure (original) (raw)

Tim Peters tim.peters at gmail.com
Thu Jul 29 23:50:57 CEST 2004

[Raymond Hettinger] ...

If we want to insist on the oballocated 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 .

* listassslice() should add a line to maintain them, * listresize() can drop the test for obitem != NULL, and * tpnew needs a custom listnew() 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.

More information about the Python-Dev mailing list