[Python-3000] Need help completing ABC pep

[Guido van Rossum]

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:
> >
> >     http://www.python.org/dev/peps/pep-3119/
> >
> > While I'm not ready yet to answer tough questions about this compared
> > to alternative proposals, I *am* ready for feedback on the various
> > open issues sprinkled throughout the current text, especially
> > concerning decisions regarding exactly which operations to include in
> > the various ABCs, and also regarding the level of detail required in
> > the PEP.
>
> Since there is no embedded copy of the PEP I am just quoting the
> various open issues and such.  That way a simple search of the PEP wil
> find what  am talking about.  At the end I have some random comments
> that do not directly mention an open issue.

Thanks!

> * "perhaps abstractmethod and AbstractInstantiationError should become
> built-ins, Abstract's functionality should be subsumed by object, and
> AbstractClass's functionality should be merged into type"
>
> Maybe, but what is the performance cost of doing the checking?  If
> it's too high I don't want to have to pay for it if I am not using
> anything that uses ABCs.  Then again, if the decision is made to run
> with this then a whole lot of stdlib code is going to end up with ABCs
> and thus the cost will be unavoidable.

Good point. Now that you mention this, and I don't understand why I
didn't already do it this way in sandbox/abc, the check could be made
at *class creation time*, and at instantiation time it should just
have to make one tiny check.

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

Already gone. I think you read the penultimate version. :-)

> * Discussing sets: "Open issue: Should this class also implement the
> operators and/or methods that compute union, intersection, symmetric
> and asymmetric difference?"
>
> If you are willing to let them just return the built-in set type
> (since one could argue that 'set' is the base type that almost any set
> will inherit from), then go ahead and add them as concrete methods.
> Otherwise leave them out.

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.

> * "Should we support all the operations implemented by the Python 2 set type?"
>
> No, only core methods should be directly supported.  Everything else
> is just convenience functions.  If these can be implemented simply as
> concrete methods then fine, but otherwise leave them out.

Sure. But one can differ about whether union() is the convenience and
__or__() the core, or vice versa. :-)

> * "Do we need BasicMapping and IterableMapping? Perhaps we should just
> start with Mapping"
>
> Just Mapping.  Doing two checks for Mapping and Iterable is not
> exactly complex.  =)

OK, I'll think about this.

> * "Also pop, popitem, setdefault?"
>
> Eh, my gut reaction is "no".  But you do have 'pop' on MutableSequence.

But for sequences it trivially maps on core methods. pop() for
mappings is a little more convoluted (how to pick a random key? Just
pick the first one I guess?)

> * Discussing sequences: "Other candidate methods, which can all have
> default concrete implementations that only depend on __len__ and
> __getitem__ with an integer argument: __reversed__, index, count,
> __add__, __mul__, __eq__, __lt__, __le__."
>
> I say go ahead and include the concrete implementation.

OK.  I was just being lazy.

> * Discussing sequences: "What about += and *=?"
>
> No.  Only worth it when a special gain is available by the implementation.

OTOH not requiring these gives them fuzzy semantics -- some mutable
sequences will return self, others a new object. That's not good. I'd
like to standardize self-modifying +=, *=.

> * "Do we have a use case for Cardinal (Integer >= 0)?"
>
> No.
>
>
> * "Do we need Indexable (converts to Integer using __index__)? Or is
> that just subsumed into Integer and should we use __index__ only at
> the C level?"
>
> I actually immediately thought of this as a use-case for ABCs when I
> started reading this PEP.  So my vote is for Indexable, although the
> name doesn't fit as the object doesn't get indexed but can be used as
> an index.  So I would rather have Index or IndexItem or something.

Index is a good one.

> * "Should we strive to use ABCs for all areas of Python?"
>
> No.  As you said, Orderable is probably the only thing really missing.
>  But if we want some inspiration we can look at what Haskell has.

Pointer? (I'm lazy. :-)

> * "Perhaps the numeric classes could be moved to a separate PEP"
>
> Well, one could argue then that we should have a PEP on how ABCs
> should work and then individual PEPs on each group of defined ABCs.  I
> suspect that if we go with ABCs we will not take their definitions
> lightly and end up haggling over definitions a lot.

Yeah, but IMO the collections are the most contentious area, and doing
these right is a motivation for the whole idea of ABCs -- it makes
more concrete "what ABCs can do for you."

> Non-open issue comments:
>
> About Iterator, does it subclass Iterable?  It seems to meet the definition.

It does, and it says so.

> I really don't like the name of Finite.  When I read the name before
> knowing what it represented I really had no clue what it represented.
> In hindsight it makes sense, but it not immediately obvious.

I have been playing with Sizeable and Lengthy, but rejected both as
being too cute. Other suggestions?

> What about 'append' on MutableSequence?

Oh, duh. It's listed as add. Will fix.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)