Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: python assignment

Reply
Thread Tools

RE: python assignment

 
 
Tim Peters
Guest
Posts: n/a
 
      07-23-2003
[Tim]
>> It would be very unusual (because bad design) for the __iadd__
>> method of a mutable type to return a pre-existing object, though.


[Juha Autero]
> I'm confused. I thought that the idea of __iadd__ is that for
> *mutable* types it modifies existing object instead of returning new
> one.


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!


 
Reply With Quote
 
 
 
 
dan
Guest
Posts: n/a
 
      07-25-2003
"Tim Peters" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> [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'.
 
Reply With Quote
 
 
 
 
dan
Guest
Posts: n/a
 
      07-25-2003
er, my example in last post should have been:

>>> for x in range(3):

.... for y in range(3):
.... temp[y] = x+y
.... v[x] = temp
....
>>> v

[[2, 3, 4], [2, 3, 4], [2, 3, 4]] #Surprise! You're in Pythonville

#fixed:

>>> for x in range(3):

.... for y in range(3):
.... temp[y] = x+y
.... v[x] = temp + []
....
>>> v

[[0, 1, 2], [1, 2, 3], [2, 3, 4]] #expected behavior

but again the +[] looks funky in the morning light. Can I always
assume that an operation of this sort will return a new object, even
if it has no effect on one of the operands?

I suppose a clearer fix would be v[x] = copy.copy(temp), eh?

"Tim Peters" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> [Tim]
> >> It would be very unusual (because bad design) for the __iadd__
> >> method of a mutable type to return a pre-existing object, though.

>
> [Juha Autero]
> > I'm confused. I thought that the idea of __iadd__ is that for
> > *mutable* types it modifies existing object instead of returning new
> > one.

>
> 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!

 
Reply With Quote
 
Steven Taschuk
Guest
Posts: n/a
 
      07-25-2003
Quoth dan:
[...]
> but again the +[] looks funky in the morning light. Can I always
> assume that an operation of this sort will return a new object, even
> if it has no effect on one of the operands?


Afaik it's not documented, but I think you may safely assume that
arithmetic on lists will always produce a new list, even in such
cases as
a_list + []
1*a_list
Having such expressions possibly return the existing object is a
harmless optimization for immutable types, but would be madness
for mutable objects such as lists. Guido is not mad. (A little
eccentric sometimes, occasionally silly, and noticeably Dutch, but
not mad.)

> I suppose a clearer fix would be v[x] = copy.copy(temp), eh?


Yes, that, or
v[x] = list(temp)
or
v[x] = temp[:]
according to taste. The latter is most common, I think.

--
Steven Taschuk http://www.velocityreviews.com/forums/(E-Mail Removed)
"[T]rue greatness is when your name is like ampere, watt, and fourier
-- when it's spelled with a lower case letter." -- R.W. Hamming

 
Reply With Quote
 
Raymond Arthur St. Marie II of III
Guest
Posts: n/a
 
      07-25-2003
Ray was tryin to follow the thread ...

Dan was talking to Tim about something.
(see below signature if your not following
thread and want to know what it's about.)

.... and Ray had a question.

>[Dan to Tim paraphrased]
>
>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'???
>


Ray's question = That last line "v[x] = temp + []",
that's equivelent to "v.append(temp)", is it not?


TIA
Ray St.Marie
(E-Mail Removed)

Thread I got this from
>"Tim Peters" <(E-Mail Removed)> wrote in message
>news:<(E-Mail Removed)>...
>> [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'.
>



 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      07-25-2003

"dan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) m...
> >>> for x in range(3):

> ... for y in range(3):
> ... temp[y] = x+y
> ... v[x] = temp + []
> ...
> >>> v

> [[0, 1, 2], [1, 2, 3], [2, 3, 4]] #expected behavior
>
> but again the +[] looks funky in the morning light. Can I always
> assume that an operation of this sort will return a new object, even
> if it has no effect on one of the operands?
>
> I suppose a clearer fix would be v[x] = copy.copy(temp), eh?


or add temp = [None]*3[] between 'for x' and 'for y' so you start with
an explicitly new temp for each x loop.

Terry J. Reedy


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Assignment operator self-assignment check Chris C++ 34 09-26-2006 04:26 AM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
Possible constant assignment operators ":=" and "::=" for Python tsaar2003@yahoo.com Python 25 05-18-2006 05:27 AM
confused about Python assignment Haoyu Zhang Python 5 10-31-2003 02:29 PM
python assignment dan Python 8 07-23-2003 10:11 PM



Advertisments