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