[Tutor] Is there any logic in this?

[jim stockford]

    essentially right reinterpretation. I believe Pythonists
use the term "bind" to describe the action of what we're
used to thinking of as the assignment operator =
    the name 'a' is bound to the list, in your former
example.

    Everything is an object in Python, including integers.
Every object persists until there are no names bound
to it, in which case the object is permanently out of
scope and eligible for garbage collection. but...
    Objects for the small integers remain in scope always.

    your example is interesting, but reading right to left
doesn't work well, which bothers me.
    I read your first line as "make 'a' reference the
integer object 10, then make 'b' reference whatever 'a'
references, then (next line) add 10 to whatever 'b'
references, but oops: under the hood the Python
interpreting system must as its first principle keep
common sense--the human wants to add 10 to 'b' so
'b' will now reference the integer object that matches
10 + 10.
    I totally made the above explanation up, so it's a
good target for skepticism.
    I hate not being able to read from right to left in a
procrustean manner. The compromise is read the
right side of the "assignment" operator and then
the left side and do what common sense expects.

    I hope one of the p-t gurus will explain better.



On Sep 1, 2007, at 8:02 AM, Righard/Riku van Roy wrote:

> Thanks for your explenation, so essentialy a = b, copys the pointer of 
> a
> to b rather than the actual content. This explains why a[:] does work.
>
> Do you have an explenation why this is not the case with integers ie.
>
>>>> a, b = 10, a
>>>> b = b + 10
>>>> a, b
> (10, 20)
>
> thx
>
>
> Op za, 01-09-2007 te 07:50 -0700, schreef jim stockford:
>>     seems to me this is an artifact of the language.
>>     reading right to left:
>> "make a list that contains 10,40,30,20, then create a
>> name 'a' to be used as a label to identify that list, then
>> (next line) create a label 'b' to attach to whatever is
>> the thing 'a' refers to, then (next line) modify the thing
>> via 'b' (e.g. b.sort)."
>>     the essence is to allow multiple names for things
>> without clogging up memory with a lot of copies and
>> to have a uniform mechanism of referencing anything
>> (i.e. any "object", for everything in Python is an object,
>> hence the utility of a uniform mechanism.
>>     the effect is programmers have to know this is the
>> case. those who have the old style "C head" using the
>> model of a variable name representing an area in
>> memory where assignment copies data to a new area
>> in memory with the other variable name will get caught
>> on this until they catch on.
>>
>>     I'll be very grateful for any criticism of the above.
>>
>>
>>
>> On Sep 1, 2007, at 6:29 AM, Righard/Riku van Roy wrote:
>>
>>> If you copy a list into another variable, and then change the second
>>> one, the first gets changed aswell, for example:
>>>
>>>>>> a = [10, 40, 30, 20]
>>>>>> b = a
>>>>>> b.sort()
>>>>>> a
>>> [10, 20, 30, 40]
>>>>>> b
>>> [10, 20, 30, 40]
>>>
>>> or:
>>>
>>>>>> a = [10, 40, 30, 20]
>>>>>> b = a
>>>>>> b[0] = 99
>>>>>> a
>>> [99, 40, 30, 20]
>>>>>> b
>>> [99, 40, 30, 20]
>>>
>>> this happens with dictionary's too, but not with intergers, it is not
>>> that this is a problem because I can just use...
>>>
>>>>>> b = a[:]
>>>
>>> ...but I wonder if there is any logic behind this, I cannot find a
>>> practical use for it, just problems.
>>>
>>> thx, Righard
>>>
>>>
>>>
>>> _______________________________________________
>>> Tutor maillist  -  Tutor at python.org
>>> http://mail.python.org/mailman/listinfo/tutor
>>>
>>
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>