On 4 Jan 2006 10:54:17 -0800, "KraftDiner" <[EMAIL PROTECTED]> wrote:
>I was under the assumption that everything in python was a refrence... > >so if I code this: >lst = [1,2,3] >for i in lst: > if i==2: > i = 4 >print lst > >I though the contents of lst would be modified.. (After reading that >'everything' is a refrence.) >so it seems that in order to do this I need to code it like: > >lst = [1,2,3] >for i in range(len(lst)): > if lst[i] == 2: > lst[i]=4 >print lst > >Have I misunderstood something? > Evidently, as others have already elaborated upon ;-) I am wondering if it might be helpful to focus on expressions first, and point out that the result is always a reference to an object representing the value of the expression. Since you always get a reference to a value-representing object, assignment can only have meaning in terms of what you can do with that reference. You can never assign a value per se. Therefore an assignment is placing the reference in a place determined by the assignment target syntax. The simplest is a bare name, and then we speak of binding a name to the value-representing object. The name belongs to some context, and name space, and an implementation will determine how to find the named binding site that will hold the reference, depending on what name space is involved. E.g. the binding site might be an optimized slot in a function's local name space. Other assignment syntaxes also create bindings, and also identify what I am calling binding sites. These sites may be within the representation of another object, and located by some computation implementing the semantics, such as finding an appropriate offset into the current representation of a list, or a hash-accessed bucket/slot of a dict etc. BTW, the implementation of finding a binding site for a non-bare-name binding is typically a method call with the method and arguments determined by the trailing end of the assignment target expression and the object whose method is to be found determined by the expression up to the trailing end. Binding site implementation is not part of the language, but the semantics of binding objects 1:1 or 1:many is. Mutable objects have assignable binding sites. Immutable objects do not (except for the "assignment" of initial binding references during their creation). Containing objects contain binding sites, not values. Binding sites must have references to some value-representing object or other if they semantically exist, though of course an implementation may manage space any way convenient if semantics are preserved. Going back to an expression again, when e.g., a name is evaluated, the name identifies a binding site somwhere, and the value of any expression (including bare name) is, as we said at the start, "a reference to an object representing the value of the expression." In the case of a bare name, we have that reference as soon as we have identified the binding site associated with the name, since that contains a reference to a value-representing object. If this reference is now assigned to a binding site identified by another bare name, we have two bare names with respective associated binding sites having references referring to the same value-representing object. IOW, python shares value representations by default. Including mutable value representations. Which means if you want a distinct mutable value equal to a given one, you need an expression that does more than evaluate to find the reference to the given one -- i.e., creates a new value-representing object using the given for information, and returns a reference the new. To a C programmer, it will be tempting to say that "binding sites" are just pointer-data locations, and references are pointers, and "value-representing-object" is just malloc'ed space for some custom struct or array or both. This could be true for a particular implementation, but I think "binding site" and "reference" as I have just used them, are also abstract concepts, capable of alternative, non-C implementation of the python semantics. So I thought I'd try this as a possible terminology, to see if it makes it any easier for anyone ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
