[Python-3000] Need help completing ABC pep

[Brett Cannon]

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.


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


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


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


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


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


* "Also pop, popitem, setdefault?"

Eh, my gut reaction is "no".  But you do have 'pop' on MutableSequence.


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


* Discussing sequences: "What about += and *=?"

No.  Only worth it when a special gain is available by the implementation.


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


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


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


Non-open issue comments:

About Iterator, does it subclass Iterable?  It seems to meet the definition.

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.

What about 'append' on MutableSequence?

-Brett