josef <jos...@gmail.com> writes: > On Aug 21, 4:26 am, Ben Finney <ben+pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list