[Python-3000] Need help completing ABC pep
Guido van Rossum
guido at python.org
Fri Apr 20 04:35:59 CEST 2007
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.
> * "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)?"
> * "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/)
More information about the Python-3000