On Thu, 3 Feb 2000, David Ascher wrote:
>
> I think you forgot one behavior:
>
> >>> t.append('Spam!')
> >>> t.append('Spam!')
> KeyError: set already contains value 'Spam!'
Mmmm... i don't think so. I can't think of a situation in which
i would want to get this exception. If i really cared i would
ask whether 'Spam!' in t.
> no? FWIW, I don't like the use of the word 'append', which to me implies a
> serial order. I'd use 'add', but that's a nit.
'append', 'add', 'insert', all okay with me. I initially avoided
'add' due to possible confusion with + and __add__, and 'insert'
because list.insert took two arguments. But, as i say, i wouldn't
be much bothered by any of these names.
> > ((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.))
>
> Isn't magnitude equality currently spelled len(a) == len(b)?
That's, uh, "size equality" (oh, i don't know, i'll make up the
terminology as i go along). That's not the same as "<=>" if you
are going to allow arbitrary partial orderings. I suppose it
depends how "arbitrary" we are willing to let them get -- a
"<=>" operator might turn out to be never needed, though it is
truly a third and different kind of equality.
a <=> b is equivalent to a <= b and a >= b
(...hence the spelling.)
-- ?!ng
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