type() new style class instance says "class", not "ObjectType"

Bengt Richter bokr at oz.net
Fri Apr 12 17:54:17 EDT 2002


On Fri, 12 Apr 2002 18:49:17 GMT, Guido van Rossum <guido at python.org> wrote:

>"David Mertz, Ph.D." wrote:
>> Unfortunately, there's more to it than this.  There still is--and
>> presumably always will be--a difference between "instances" and other
>> types of things.  For example, a list is a mutable sequence that has
>> some items in it.  In contrast, an instance object--whether new style or
>> old style (and w/ or w/o __slots__)--is a thing that has some
>> attributes.  The basic shape of the data will always be different.  The
>> type/class unification doesn't change that.
>
>Hm...
>
>So after
>
>    class C(list):
>        def appendmany(self, *args):
>            for arg in args:
>                self.append(arg)
>
>Do you consider a C instance to be a list or an instance?
>You might look at the presence of a __dict__ attribute
>storing instance attributes as the distinguishing factor.
>But then what would you do after
>
>    class D(list):
>        __slots__ = ["foo"]
>
>List or instance?  The shape of a D instance is the same
>as the shape of a list, but with an extra slot added.
>
ISTM what matters most of the time is how you can use it, not
what its exact parentage is. E.g., people (ab)use type(x) to
try to check if an argument to a function should be used one
way or another way. I'm wondering if we're heading towards
a hascapability(thing, cap) kind of general query, as a useful
standard set of capabilities objects can be endowed with evolves?

hasattr(c, '__getitem__') etc. can answer some of those questions,
but if you had an official enumerated set of capabilities, you could
have a __capabilities__ slot and check with a mask (e.g., against
constants in __builtins__, e.g., INDEXING).

For your class above people might write hascapability(c, INDEXING) or
c.__capabilities__&INDEXING rather than type(c) is list (which fails)
or isinstance(c, list) which might be unnecessarily narrow for the
generic capability (which a non-list-based custom object might support).

BTW, A standard capabilities/protocol query method might be something to
reserve a mask bit for, for custom extension of the concept.

Regards,
Bengt Richter



More information about the Python-list mailing list