Object Reference question

Ben Finney ben+python at benfinney.id.au
Fri Aug 21 18:52:21 EDT 2009


josef <josefg at gmail.com> writes:

> On Aug 21, 4:26 am, Ben Finney <ben+pyt... at benfinney.id.au> wrote:
> > Note that, after that list is created, each item in that list is
> > *also* a reference to the corresponding object. That is, ‘a’ is a
> > reference to an object, and ‘dk[0]’ is a *different* reference to
> > the *same* object. The object has no knowledge about those
> > references.
>
> This is surprising.

Perhaps so, depending on your initial assumptions. But it's quite
consistent: every time you use an object, you do so via some kind of
reference to that object. Those references are the way you get at the
same object again later.

> My initial thought is that dk[0] hold the object reference 'a,' but
> that wouldn't be true "pass by object reference."

Right. It stores an entirely *separate* reference to that object. The
reference ‘dk[0]’, a list item, and the reference ‘a’, a name, both
refer to the same object. Neither of those references knows anything
about the other.

> When defining the object reference dk[0]

Not “defining”. You're binding (“assigning”, if you like) a reference.

> python takes the object reference 'a,'

More accurately, it takes the object referred to by ‘a’. (Also, please
don't put the comma inside the quotes; it's syntactically significant,
and changes the meaning of what you're writing in code.)

> finds the object MyClass0()

No. ‘MyClass0()’ is syntax for “call MyClass0 and get its return value”.
The return value will be a new instance of the class — a *new* object
every time you use that syntax.

Rather, the object referred to by ‘a’ will be the result of evaluating
the identifier ‘a’. As a shortcut for discussion, you can talk about
“the object ‘a’”, but remember that the only things you're using in the
syntax of your Python code is object *references*, be they identifiers
(names) or some other kind of reference.

> and then assigns the object identity to dk[0]? Or something close to
> that.

You'd do well to read <URL:http://effbot.org/zone/python-objects.htm>
for a good, simple coverage of the Python object model.

> I'm a bit shocked that there isn't a method for catching object
> reference names.

Don't be; there is no such thing as an “object reference name”.

A name is an object reference. So is every other way of getting at a
Python object in your code.

> I think that something like a = MyClass0(name = 'a', ...) is a bit
> redundant.

It usually is, yes. Why do you think you need it? The natural way to
handle objects and names together in Python is with a mapping; a ‘dict’
instance.

> Are definitions treated the same way? How would one print or pass
> function names?

Functions are objects like any other, but since they're more likely to
want to know their own name, the name is stored as an attribute::

    >>> def frobnicate_nodule(spam):
    ...     """ Frobnicate the spam nodule. """
    ... 
    >>> type(frobnicate_nodule)
    <type 'function'>
    >>> frobnicate_nodule.__name__
    'frobnicate_nodule'

The fact that the function name is stored in one of those funky
double-underscore names is a big clue that the attribute is special (in
this case, because it gets assigned automatically by the Python
interpreter).

That's not the case for most types, though.

> I think I'll just add a 'name' to the classes' init defintion.

What is the larger problem you're trying to solve, and why do you think
it will be helped by instances knowing a name for themselves?

(Note: an object can never know *all* names for itself, let alone all
the other references to itself; and you must write your program in the
knowledge that no reference to an object has any intrinsic special
status against any of the other references to that object.)

-- 
 \        “I spent a lot of money on wine and women, and like a fool I |
  `\                                 squandered the rest.” —Benny Hill |
_o__)                                                                  |
Ben Finney



More information about the Python-list mailing list