[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4