I've also sometimes thought of unifying dicts and sets by implementing
set operations on the keys of dicts only. When the values aren't the
same, we could make an arbitrary decision e.g. the left operand wins.
You get quite far. E.g.
a = {1: "a", 2: "b"}
b = {1: "c", 3: "d"}
# These already work:
assert 1 in a
assert 1 in b
assert 3 not in a
# etc.
# These would be new (the equivalent augmented assignments would work too):
assert a|b == {1: "a", 2: "b", 3: "c"}
assert a&b == {1: "a"}
assert a^b == {2: "b", 3: "d"}
assert a-b == {2: "b"}
assert b-a == {3: "d"}
# We could use these equivalencies:
assert {1} == {1: None} == set({1: "a"}) # I.e. canonical sets have
all None values
# And of course it would solve the empty set notation problem nicely:
assert dict() == {} == set()
Unfortunately we couldn't redefine <=, <, >=, > to mean various
subset/superset tests without backwards incompatibilities (but does
anyone care?), and == and != would of course take the values into
account which would occasionally sting. Also, sets would grow some
operations that don't make a lot of sense (e.g. __getitem__, get,
setdefault) but that's minor once you know the same implementation is
used.
I still expect there's a fatal flaw in the scheme, but I can't think
of it right now...
--Guido
On 7/8/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > moreover, you can say a set is a "kind of" a keys-only dict. in fact,
> > the first implementation of set used a dict, where the keys where the
> > elements of the set, and their value was always True.
>
> Or you could adopt the approach used by SETL: A dict is equivalent to a set
> of 2-tuples. In other words, {1:2, 3:4} could be defined as being
> equivalent to {(1,2), (3,4)}, with the run-time system being responsible for
> maintaining the information needed for efficient associative access. Then
> there's no question about the type of {}, because there's really only one
> type.
>
> No, I'm not serious; I think it would be too big a change. But you have to
> admit it's a cool idea :-)
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
