[Python-checkins] r54986 - peps/trunk/pep-3119.txt

[Jim Jewett]

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