python assignment

dan danbmil99 at yahoo.com
Thu Jul 24 22:15:35 EDT 2003


"Tim Peters" <tim.one at comcast.net> wrote in message news:<mailman.1058992140.17079.python-list at python.org>...
> [Tim]
...
> Bjorn added more appropriate words -- it would be bad design for the
> __iadd__ method of a mutable type to return a pre-existing object other than
> self.
> 
> >>> a = [1, 2]
> >>> b = [1]
> >>> b += [2]
> 
> While "a == b" must be true at this point, it would be a nightmare if "a is
> b" could be true at this point.  For immutable types it doesn't matter:
> 
> >>> a = (1, 2)
> >>> b = (1,)
> >>> b += (2,)
> 
> It so happens that "a is b" is not true at this point under any Python
> released so far, but it could be true someday without causing harm.
> 
> Sorry for the confusion!

Ok, that makes sense to me.  I still think it would be a good idea to
put a section in the Tutorial -- perhaps under "for computer
scientists and those who want to learn more" -- describing how Python
binds names to objects.

In particular, the fact that a list is a list of pointers, not the
objects themselves, seems like an important point to make, even for
relative newcomers.

Here's the thing that tripped me up, and the solution I came up with,
which I am now unsure of:

#original code -- v[] is a list

  for x in range(n):
    temp = [x+y for y in range(3)]   #or whatever
    v[x] = temp

so I was quite surprised to find all members of v[] were in  fact
pointers to one object, temp[].

My solution, which I'm worried about, was this:

  for x in range(n):
    temp = [x+y for y in range(3)]   #or whatever
    v[x] = temp + []                 #'assignment by copy'???

So I'm still unclear as to whether an expression like temp+[] is
defined as returning a new list or not.  Seems like it might be
undefined, since either way is arguably 'correct'.




More information about the Python-list mailing list