[Python-checkins] r54986 - peps/trunk/pep-3119.txt (original) (raw)

Jim Jewett jimjjewett at gmail.com
Thu Apr 26 21:30:48 CEST 2007

On 4/26/07, guido.van.rossum <python-checkins at python.org> wrote:

New Revision: 54986

peps/trunk/pep-3119.txt + Open issues: Should _or_ and friends be abstract or + concrete methods? ... ...

+ Perhaps the right choice is to have a static concrete factory + function fromiterable which takes an iterable and returns + a ComposableSet instance.

I like it; it seems to clutter the interface a bit, but for sets, it probably is a reasonable requirement that there be such a constructor. And in the worst case, they get a builtin set instead of their own type, but only for methods they didn't bother to implement.

+ The following invariant should hold for any mapping m:: + + set(m.items()) == set(zip(m.keys(), m.values())) + + i.e. iterating over the keys and the values in parallel should + return corresponding keys and values. Open issues: Should + this always be required? How about the stronger invariant using + list() instead of set()?

You might as well; I can certainly imagine an implementation that does not march in parallel for keys and value; it is hard to imagine a (non-silly) example that keeps those two in parallel, but somehow forgets the order when grabbing them together.

+Open issues: If all the elements of a sequence are totally +ordered, the sequence itself can be totally ordered with respect to +other sequences containing corresponding items of the same type. +Should we reflect this by making Sequence derive from +TotallyOrdered? Or Partiallyordered?

I don't think it is TotallyOrdered, because some sequence instances will have unordered elements. Saying it is PartiallyOrdered might start down the road of placing too many constraints on the ordering of ABC bases. (Unless you use the non-inheritance way to assert this...)

Also, we could easily +define comparison of sequences of different types, so that e.g. +(1, 2, 3) == [1, 2, 3] and (1, 2) < [1, 2, 3]. Should we? +(It might imply ["a", "b"] == "ab" and [1, 2] == b"\1\2".)

I think that might be too much of a backwards-compatibility problem.

If (("1", "2", "3") == "123"), that will shrink some dictionaries.

-jJ

More information about the Python-checkins mailing list