(BTW, perhaps the __contains__ changes should be extended to __max__ and __min__? They share many of the same issues.)
I suppose so, although I think the uses of a smart __contains__ are much more frequent than the uses of a smart __max__.
That's probably a reflection of the fact that min/max are less frequently used than 'in'. (Which is reflected in making min/max "mere" functions while 'in' is a built-in operator.) I was thinking of any sequence representation that keeps its items sorted (like the old ABC "lists"). Of course, if you're using a hash table, 'in' is trivially answered, but min/max aren't.
On the other hand, I do think that it might be nice to have that sort of hook in the rich array world...
Really? The min/max functions already do all their looping in C.
On the topic of rich comparisons, I think I have a complete game plan in my head, if not in code. I had to do some figuring out of the mods to the compilation phase to allow short-circuiting with minimal performance impact, as you and Jim H. discussed on the list way back when. But, as you can guess, I'm a bit short on time. [For those of you who don't know, I have a 4-day old daughter at home, and, more relevantly, she has an older brother =)].
[I guess you get to worry about the older brother while your wife takes care of the newborn? :-)]
I would really like a bit more discussion and decision on coercions before finalizing the rich comparison patches, as I think a coherent coercion strategy will help simplify the patches. Marc-Andre is short on time due to the Unicode stuff, and he posted a teaser to spark some discussion, which got no response at all. I'm not surprised, it's an ugly problem. Did anyone have thoughts that they'd want to share on the topic?
I have no children [yet], but Python is my baby -- and I'm way overcommitted to other Python projects. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)