[Python-3000] PEP 3119 - Introducing Abstract Base Classes

Thomas Lotze thomas at thomas-lotze.de
Fri Apr 27 20:53:35 CEST 2007

Guido van Rossum wrote:

>     Another constraint is that hashable objects, once created, should
>     never change their value (as compared by ``==``) or their hash value. 
>     If a class cannot guarantee this, it should not derive from
>     ``Hashable``; if it cannot guarantee this for certain instances only,
>     ``__hash__`` for those instances should raise a ``TypeError``
>     exception.

Shouldn't this rather be a ValueError since it occurs not because of the
type of the object in question, but its value (while in general, there are
instances of the same type representing other values which are hashable)?

>     The third one is for subsequence
>     checking on (character or byte) strings, which is also slow: O(N).
>     Would it make sense to distinguish these?  The signature of the third
>     variant is different, since it takes a sequence (typically of the same
>     type as the method's target) intead of an element. For now, I'm using
>     the same type for all three.  This means that is is possible for ``x
>     in o`` to be True even though ``x`` is never yielded by ``iter(o)``. 
>     A suggested name for the third form is ``Searchable``.

To me, 'searchable' isn't associated with subsequences in any way. I'd
think of a container that is able to answer the question "where is this
element?" A sequence might return an index or a set of indexes, a mapping
might return a key or a set of keys in reply to this. If what you're after
is really a subsequence containment test, it should just live on sequences
instead of getting an ABC of its own, IMO.

> **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``?

Unless I'm mistaken, since a sequence type in general can't know whether
all the elements in a given instance will be totally ordered, deriving
Sequence from TotallyOrdered would make promises it can't keep. But I'm +1
on deriving Sequence from PartiallyOrdered since sequences do have an
ordering relationship between some of their values.

> 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"``.)



More information about the Python-3000 mailing list