[Python-Dev] RE: test_sort.py failure

[Raymond Hettinger]

> 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 list_ass_slice() to reset
ob_item
> to NULL
> > and ob_size to 0 without resetting ob_allocated 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 list_resize(), 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 empty_ob_item hack but just check that ob_allocated is
still
> zero in
> > addition to ob_size.
> 
> Too ugly; I don't think either of us *liked* the empty_ob_item hack,
> and if I was going to piss away more time on this I was determined to
> get rid of it <wink>.

That would be nice.  list_sort() serves as the model for how to defend C
code against list mutation.



Raymond