[Ka-Ping Yee]
> ...
> 2. How do sets sort?
>
> We could insert them somewhere in the hierarchy of types
> next to lists and tuples. Currently () > [] > {}, so we
> could have () > [] > {,} > {} for example.
Mixed non-numeric types currently sort by alphabetical order of type name,
so
"list" < "set" < "tuple"
Since it's utterly arbitrary, there's no reason to depart from this
(currently consistent) precedent.
> More tricky is the question of what to do with the partial
> ordering created by >, >=, etc.
>
> a. The answer is the same as whatever answer we get when
> Python supports rich comparisons and instances can have
> partial orderings too.
Yes, that's the best.
> ...
> (Side note: Do we achieve a. just by divorcing __cmp__ from
> >, >=, etc.? sorting would use __cmp__,
In anticipation of rich comparisons, the 1.5.2 list.sort() already looks
only at whether cmp's result is (or isn't) < 0. So it's also now easy to do
sorting solely in terms of __lt__.
> while > and < would look for __gt__, __lt__, etc., and if not
> found, fall back on __cmp__.
You're reinventing what rich comparisons will *always* do, here -- leave
that to David Ascher, cuz it's a mess <0.9 wink>.
> ...
> such promises. Side side note: which of these promises, if
> any, should we ask __gt__ et al to make? Stability, at least?)
The ones that make obvious sense for __gt__ etc, of course. There's no
point in introducing a type for which it's not guaranteed that, e.g., a<b is
deterministic. That kind of stuff is so basic it's not even mentioned in
the docs now (hmm -- maybe it should be).
> ((Side side side note: in E, Mark Miller also ran into the
> problem of spelling different kinds of "equals"es. For
> object identity we have "is", for content comparison we
> have "==". If we need a new operator for magnitude equality
> i suggest "<=>", as used in E.))
I don't know what "magnitude equality" means. If it means comparing by
cardinality, people should use explict "len". <=> is likely a poor choice
regardless because that's the way Perl spells Python's cmp (or mabye that's
what mag. eq. means?).
> Well, it may be a lot of words, but it's not much good unless you
> are going to use it in practice. I think i would have good use for
> it, but i would like to hear your opinions. Would you use such a
> thing?
Yes, but Guido won't accept it <wink>. In my own Set classes, I eschewed
operator overloading because I found that, in practice, I routinely need
both functional and mutating forms of all the basic operations (inclusion,
intersection, union, difference, symmetric difference). I also needed to
dream up a scheme to allow Sets of Sets (& so on). A truly useful set type
needs to be very rich! Which is another reason (see earlier post for the
other) Guido won't want this (the inability to subclass builtin types in
Python today means he would have to arbitrate the whole universe of possible
set methods, and that's a time sink with small payback).
when-desire-meets-reality-guido-wins<wink>-ly y'rs - tim
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