On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 4/30/07, Collin Winter <[EMAIL PROTECTED]> 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 _______________________________________________ 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
