Guido van Rossum wrote:
> 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.
If the right operand always won then a |= b would be equivalent to a.update(b).
> # And of course it would solve the empty set notation problem nicely:
> assert dict() == {} == set()
So dicts would always start life using the set implementation, and switch to
the full dict implementation only when a non-None value was added?
> Unfortunately we couldn't redefine <=, <, >=, > to mean various
> subset/superset tests without backwards incompatibilities (but does
> anyone care?
You mean those are defined *now*? I'm trying to figure out what the heck they
could even mean. . .
> I still expect there's a fatal flaw in the scheme, but I can't think
> of it right now...
If you've got an idea of how to handle the promotion from the set
implementation to the dict implementation when a non-None value is entered,
then I can't see any fatal flaws, either.
I'm sure Raymond will be able to come up with something, though :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
