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

fdrudol5 at rockwellcollins.com fdrudol5 at rockwellcollins.com
Fri Apr 27 20:25:07 CEST 2007


The PEP looks good. A few nits and a couple of related questions:

MutableSet.pop() "...removes an arbitrary..." # should be "...removes and
returns an arbitrary..."

BasicMapping .__contains__() # should be .__contains__(key)

In Mapping.__eq__, "if and only iff" is redundant. And yes, I think the
stated semantics are useful.

The invariant   set(m.items()) == set(zip(m.keys(), m.values()))
is not strong enough and using list wouldn't fix it. A really goofy
implementation that iterates
values in a different order than keys, then defines items as returning the
zip would satisfy
the invariant. How about:
      [value for value in m.values()] == [m[key] for key in m.keys()]
      [item for item in m.items()] == [(key, m[key]) for key in m.keys()]
Do we need to explicitly state the invariant   len(m.values()) ==
len(m.keys())?
Is this an invariant?  all(isinstance(item,tuple) for item in m.items())

Really minor nit: inconsistent use of "." and "()": ".pop()", ".clear()",
but "items", "values", etc.

In Sequence, the other method candidates all make sense, should have
standard semantics,
and have easy default implementations. Might as well do it.

Can the standard ABCs be usefully superclassed? For example, in a class for
potentially infinite
sets that can be unioned and intersected with builtin sets, would
__subclass__ = {ComposableSet}
be useful?

In the context of parameter annotations, having homogeneous containers
(sets of strings, sequences
of integers) were discussed. Can wrappers be created so that a content
invariant can be enforced
on a container and easily checked against a constraint on a formal
parameter?

#Rudy



More information about the Python-3000 mailing list