Guido van Rossum wrote: > But do we really want this? It's a pretty serious change in basic > semantics of collection data types, *and* it requires us to find a way > to determine unequivocally whether something is a set, sequence, > mapping, or multiset (and it can't be more than one!).
If we *did* want it, I think there would have to be a collection of abstract types -- SequenceBase, MappingBase, SetBase, etc., that all types wanting to participate in this scheme would have to be based on. Since this would go against duck typing, my feeling is no, we don't want it. If it's okay for lists and tuples containing the same items to be unequal even though they're both sequences, then I think it's okay for a real set not to be equal to a set view of something. If you really want to be able to compare different set-like objects, there could be a function for that. Or even a bunch of functions for doing set operations on set-like objects. There's a precedent for this in Numeric. The Numeric array objects know how to do arithmetic with each other, but there is also a set of functions add(), multiply(), etc. which do the corresponding things with any objects that can be treated as sequences of sequences. It could be worth having a set of functions like this in the core for doing sequence operations, set operations, etc. -- Greg _______________________________________________ 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
