[Python-Dev] binary trees. Review obmalloc.c

Josiah Carlson jcarlson at uci.edu
Wed May 3 10:25:35 CEST 2006

"Vladimir 'Yu' Stepanov" <vys at renet.ru> wrote:

> Comparison of functions of sorting and binary trees not absolutely 
> correctly. I think that function sort will lose considerably on
> greater lists. Especially after an insert or removal of all one element.

Generally speaking, people who understand at least some of Python's
internals (list internals specifically), will not be *removing* entries
from lists one at a time (at least not using list.pop(0) ), because that
is slow.  If they need to remove items one at a time from the smallest
to the largest, they will usually use list.reverse(), then repeatedly
list.pop(), as this is quite fast (in general).

However, as I just said, people usually don't remove items from
just-sorted lists, they tend to iterate over them via 'for i in list:' .

 - Josiah

As an aside, I have personally implemented trees a few times for
different reasons.  One of the issues I have with most tree
implementations is that it is generally difficult to do things like
"give me the kth smallest/largest item".  Of course the standard
solution is what is generally called a "partial order" or "order
statistic" tree, but then you end up with yet another field in your
structure.  One nice thing about Red-Black trees combined with
order-statistic trees, is that you can usually use the uppermost bit of
the order statistics for red/black information.  Of course, this is
really only interesting from an "implement this in C" perspective;
because if one were implementing it in Python, one may as well be really
lazy and not bother implementing guaranteed balanced trees and be
satisfied with randomized-balancing via Treaps.

Of course all of this discussion about trees in Python is fine, though
there is one major problem.  With minimal work, one can construct 3
values such that ((a < b < c) and (c < a)) is true.

More information about the Python-Dev mailing list