On 4/30/07, Bill Janssen 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