[Python-3000] Need help completing ABC pep

[Jim Jewett]

On 4/19/07, Guido van Rossum <guido at python.org> wrote:
> On 4/19/07, Brett Cannon <brett at python.org> wrote:
> > On 4/19/07, Guido van Rossum <guido at python.org> wrote:
> > > I've started a PEP on Abstract Base Classes (ABCs), PEP 3119:

> > * "Should we also implement the issubset and issuperset methods found
> > on the set type in Python 2? As these are just aliases for __le__ and
> > __ge__, I'm tempted to leave these out."

> > Leave them out.  Not terribly needed plus it is better to start out
> > small.  They can easily be added later if called for.

I think the names are more sensible than repurposing the numeric
operators.  The "concrete" implementation can just forward to other
name, so it doesn't cost much.

> I doubt that 'set' will be inherited from much (except for trivial
> stuff) but returning a 'set' does make some sense. Although for
> trivial subclasses (e.g. adding a different repr or a brand new
> method) you'd like the results also to be an instance of the subclass.
> If we could find a way to do that it would be best.

You could use a variant of the numeric operator resolution.

The left class wins, unless the right class is a subclass of the left.
If this class does not have a constructor that accepts an iterable,
(maybe fall back to the other class, then) fall back to a builtin set.

Going back to the PEP itself, in the ABC support framework, I would change:

"We define the following four new built-in objects that help defining ABCs:"
->
"We define the following four new objects (in module abc) that help
defining ABCs:"

and in the @abstractmethod description,


"Such a method may be called"
->
"These abstract methods may still be called"

In the Hashable section:

> 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.

Why not just return -1 (unless/until the value is stable)?  Is the -1
special case being phased out too?

...
I would say that Searchable might be worth separating into a Container
subclass, but don't worry about the speed differences.  Many
containers are small enough that constant effects are more important
than big-O.  When big-O does matter, then the user may well want to
distinguish between the O(1) and O(log N) case.  I think this gets
detailed enough that it isn't worth putting in the common library.

Why must a HashableSet or MutableSet be composable?  If this is
because you figure any useful set has those properties (and I don't
think so, when doing uniquification), then Set and ComposableSet
should become BasicSet and Set?

...

Note that in the current sandbox  sandbox (which doesn't have
*Ordered), the name BasicSet is used for a Set which isn't Sized.
(Except that Set doesn't actually inherit from BasicSet, as I assume
it should do.)

Continuing with the current sandbox

Why must @abstractmethod come last, when mixed with other decorators?

IterableMapping needs to override __iter__; as written, it returns the
empty iterator.

Should Sequence.index take optional start and stop arguments?

    def index(self, value, start=0, stop=None):
        if stop is None:
            stop = len(self)
        for i, elem in enumerate(self):
            if i < start:
                continue
            if stop < i:
                break
            if elem == value:
                return i
        raise ValueError

-jJ