[Python-3000] Need help completing ABC pep

[Brett Cannon]

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:
> > >
> > >     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!
>

No problem.  Gave me something to do while I waited for my girlfriend
to get off of work.  =)

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

I thought you were already doing that.  =)  I was just worried that it
would be prohibitively expensive at class creation time for some short
script that used mostly stdlib code that happened to use ABCs.

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

Quite possibly.  Did this all offline.

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

Well, self.__class__() would work, right?  That should resolve
properly.  Or maybe we need that super keyword.  =)

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

So I say base it on ease of implementation.  If it can be done
trivially in five lines of Python code then include it, otherwise let
the user do it.

> > * "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?)
>

Right, which is why my gut reaction was "no".  I don't know how you
choose.  But if you are popping off of a mapping object you should
know the order will be undefined.  I would take your latter
suggestion: get a list of keys, take the first one and use that as
what gets popped off.

> > * 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 +=, *=.
>

Then I guess you answered your own question.  If you were asking about
semantics I would just follow what lists do.

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

Damn, I guess I have to do a little extra work now....

See http://haskell.org/onlinereport/prelude-index.html for the Haskell
98 report and the prelude (Haskell's version of built-ins).  You care
about the type classes (which they just call "classes" on the page).
If you follow the links for any of the type classes they will tell you
exactly what functions must be defined for something to meet that type
class.  Some of them are Haskell-specific, but not all.

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

Gotcha.

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

Ah, see it now.

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

Umm, Sized?  =)  Basically, no, I don't have a better suggestion.

> > What about 'append' on MutableSequence?
>
> Oh, duh. It's listed as add. Will fix.

Ah.  =)  I just figured 'add' was some method to specify where to
insert a value or something.

-Brett