On 4/19/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 4/19/07, Guido van Rossum <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
