A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2004-July/046557.html below:

[Python-Dev] RE: test_sort.py failure

[Python-Dev] RE: test_sort.py failureRaymond Hettinger python at rcn.com
Thu Jul 29 12:06:19 CEST 2004
> I want to insist on *documented* invariants

Absolutely.


> but I don't particularly
> care what they are. 

Right.  I just wanted to point out an alternative invariant that did not
rely on knowledge of the ob_allocated field.



> The idea that "list.ob_item == NULL implies list.allocated may be
> lying" is at least as obscure as the invariant that broke, 
 . . .
> 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>.

Okay.  Those good reasons to prefer the invariants you just documented.


> > * list_ass_slice() should add a line to maintain them,
> > * list_resize() can drop the test for ob_item != NULL, and

Will put these in.



> * tp_new needs a custom list_new() establishing the invariants.
>
> > 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.

Right.  I remembered that after I sent the last note.  Will add a
comment in list_init so it doesn't get forgotten again.



Raymond

More information about the Python-Dev mailing list

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