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

[Steven Bethard]

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