[Python-3000] PEP 3119 - Introducing Abstract Base Classes (original) (raw)

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