Is 'everything' a refrence or isn't it?

Fredrik Lundh fredrik at
Sun Jan 15 04:48:22 EST 2006

Bryan Olson wrote:

> I think the following is correct: an object's identity is not part
> of its value, while its type is.

you're wrong.  an object's identity, type, and value are three different
and distinct things.  the identity and type are not part of the value.  the
type controls *how* to access the value, and needs to be known *before*
you can access the value.

(CPython solves this by letting an object reference point to a structure
with two known fields and an opaque value block; other implementations
may use other ways to associate identities and types with references.
A Python runtime that uses a copying garbage collector must store the
object identity separately as well, since the identity be stable even if
the reference changes.  A runtime that uses references that don't fit
in integers may have to do the same.)

> I don't think usage of "query" is the issue.

If you define "query an object" as "query an objects value via the type
mechanism" (which is what I had in mind), the rest of your argument is
just plain wrong.  If you define it as "look inside some data structure used
by the computer", further discussion is meaningless, since all terms can
then mean anything.

> Python queries objects for their types; it's now a user-visible feature:
>      >>> 'hello'.__class__
>      <type 'str'>

To get an object's type, use type(x).  This has always been a user-
visible feature (along with id(x)).

__class__ is simply a property on the object baseclass that returns
type(self) for new-style classes.  Overriding __class__ doesn't change
the behaviour of the type function, and doesn't change the object's

    >>> class foo(object):
    ...     __class__ = "oops"
    >>> f = foo()
    >>> type(f)
    <class ''>
    >>> f.__class__

If type queried the object, type(f) and f.__class__ would have returned
the same thing.

(with old-style classes, all instances belong to the instance type, and
type(x) and x.__class__ give different results from the start)

> Python would still be duck-typed and the type would still be a
> property of the object.

Nobody's saying that the identity and the type is not a "property" of the
object (for a suitable definition of property, that doesn't include Python
properties).  What the documentation and I are saying is that it's not a
part of the object's *value*.

An object's identity, type, and value are three different and distinct things
(or "properties", if you prefer).  End of story.


More information about the Python-list mailing list