[Python-Dev] RE: test_sort.py failure (original) (raw)
Raymond Hettinger python at rcn.com
Thu Jul 29 09:21:30 CEST 2004
- Previous message: [Python-Dev] RE: test_sort.py failure
- Next message: [Python-Dev] RE: test_sort.py failure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I confess I made no effort to verify that the invariants actually hold. My view was that the invariants were so mild and so necessary that any violation discovered should (and would) be treated as a bug.
> E.g. it is unclear to me why we allow listassslice() to reset ob_item to NULL > and obsize to 0 without resetting oballocated to 0 Since that violates one of the now-documented invariants, you can guess my position on that. > -- I see why it doesn't crash in a subsequent listresize(), but it looks messy.
list_resize() doesn't assume a valid value for ob_allocated unless ob_item != NULL. The idea was to avoid imposing new invariants on the list structure so that the remaining code and extensions would be easier to maintain. Ideally, no code outside of PyList_New() and list_resize() would need to know about the ob_allocated field.
If we want to insist on the ob_allocated invariants, then
- 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.
> Alternatively, the quickest fix for the broken listsort() would have been to > keep the emptyobitem hack but just check that oballocated is still zero in > addition to obsize.
Too ugly; I don't think either of us liked the emptyobitem hack, and if I was going to piss away more time on this I was determined to get rid of it .
That would be nice. list_sort() serves as the model for how to defend C code against list mutation.
Raymond
- Previous message: [Python-Dev] RE: test_sort.py failure
- Next message: [Python-Dev] RE: test_sort.py failure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]