[Python-3000] Traits/roles instead of ABCs

Collin Winter collinw at gmail.com
Mon Apr 30 20:01:58 CEST 2007


On 4/30/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 4/30/07, Collin Winter <collinw at gmail.com> wrote:
> > No existing mechanism would allow PEP 3141 to be distributed as a
> > third-party module and still impact the built-in types; that's what
> > this whole business of __isinstance__ and __issubclass__ is about. In
> > order to achieve dynamic composition, we're having to monkey with
> > fundamental, bedrock properties of inheritance-based object
> > orientation. The definition of "subclass" and "instance" is no longer
> > objective; the answer to "is X an instance of Y?" becomes, "I dunno,
> > ask Y".
>
> I guess I don't understand why this bothers you more than how you can
> currently mess with __class__::
[snip]
> Maybe you could give a couple realistic examples of where you think
> people using __isinstance__ and __issubclass__ are going to break
> things unintentionally?

You assume that being able to change __class__ doesn't bother me: it
does. The thing that mitigates my unease is that it comes with a
gigantic red flag that boils down to, "Don't even think about this
unless you're implementing proxy objects".

By pushing capabilities tests into the core object system and making
isinstance() and issubclass() the primary mechanisms for determining
an object's behaviour, you're making it standard practice to monkey
around with inheritance. Do I have specific examples of what I'm
afraid of? No. All I can offer is a deep distrust of a system where
metaclasses and a redefined concept of inheritance are pulled out so
early in the debate in order to solve issues that other mechanisms
(like roles) make trivial.

Collin Winter


More information about the Python-3000 mailing list