[Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities) (original) (raw)

Steven Bethard steven.bethard at gmail.com
Mon Apr 30 19:38:14 CEST 2007

On 4/30/07, Bill Janssen <janssen at parc.com> wrote:

GvR wrote: > So how about we reduce the scope of our (!) PEP (or perhaps of a new > one) to two items: (a) add @abstractmethod, and (b) overload > isinstance() and issubclass()? Library authors can do everything they > want with those, and we can always add a specific set of ABCs for > containers and/or numbers later in the 3.0 development cycle.

-1. Adding mechanism without content seems less than ideal, despite Talin's misgivings. I'd recommend adding the base classes in, and see how they work in the earliest 3.0 releases, then modify them as necessary in subsequent releases.

+1 for Guido's simplified PEP. There are clearly use cases for @abstractmethod, isinstance() and issubclass(), so I see no reason why the simplified PEP shouldn't be acceptable on its own. Complaining about "adding mechanism without content" seems like saying, for example, that we shouldn't have introduced "functools.partial" without using it somewhere in the standard library. Whether the use cases are in the standard library or somewhere else should not determine whether a PEP is acceptable or not.

I personally think the simplified PEP is a great compromise -- proponents of ABCs will now be able to introduce them (even for existing types like 'int' and 'list') and folks that don't want ABCs can simply never install the ABC module. Plus, it's much easier to add a module to the standard library than it is to remove one (even given Python 3.0's somewhat laxer first release plans).

STeVe

I'm not in-sane. Indeed, I am so far out of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

More information about the Python-3000 mailing list