> i'd like to know, too. my take so far is
>
> * don't make any copies if you can avoid doing so,
> * make shallow copies if need be,
> * make deep copies only if you can't think of any
> other way to accomplish what you're up to.
Yep. That's pretty much it, for space reasons, mostly. Imagine a li
#x27; is "what a pain,
> how stupid" etc, but I'm sure there is a good explanation. Can
> someone explain why python acts this way? faster processing?
> preserve memory? etc?
>
> Thanks for all your help.
>
> -Keith
> - Original Message
>
4) The typical knee-jerk reaction to this 'oddity' is "what a pain,
how stupid" etc, but I'm sure there is a good explanation. Can
someone explain why python acts this way? faster processing?
preserve memory? etc?
This comes down (largely) to a philosophical choice. Does
the language
ot;what a pain, how
stupid" etc, but I'm sure there is a good explanation. Can someone explain why
python acts this way? faster processing? preserve memory? etc?
Thanks for all your help.
-Keith
- Original Message
From: Luke Paireepinart <[EMAIL PROTECTED]>
To: Brett
Cheers, I actually forgot about the whole shallow-copy thing, and
deepcopy(). I'm only new to the language myself, I just remembered about
the slice copy and thought to mention it.
Luke Paireepinart wrote:
> Brett Wilkins wrote:
>> As everybody else has told you, assigning bb = aa just gives bb
Brett Wilkins wrote:
> As everybody else has told you, assigning bb = aa just gives bb the
> reference to the same object that aa has. Unless I missed something,
> then nobody's actually mentioned how to make this not happen... and it's
> actually rather easy... instead of bb = aa, do this:
> bb
As everybody else has told you, assigning bb = aa just gives bb the
reference to the same object that aa has. Unless I missed something,
then nobody's actually mentioned how to make this not happen... and it's
actually rather easy... instead of bb = aa, do this:
bb = aa[:]
Looks like a splice, a
So the problem is that when I change bb, aa also changes even
though I don't want it to. Is this supposed to happen?
Yes
Names are handles for objects. Assignment binds
a name to an object. The same object can be
bound simultaneously to many names.
Python distinguishes between equality an
i'm guessing this is the "post-it effect".
aa = range(0,10)
print aa
[0,1,2,3,4,5,6,7,8,9]
# what you've done is to use the range function to
# create the list of 0 to 9, then you associated the
# name aa to the list. a popular teaching analogy
# is that of putting a post-it that says aa on the l
On Wed, 27 Feb 2008, Keith Suda-Cederquist wrote:
> Hi,
>
> I'm using iPython and I've run into an occasional problem that I don't
> understand. Here is what I'm seeing:
>
> >>aa=range(0,10)
> >>bb=aa
> >>print aa
> [0,1,2,3,4,5,6,7,8,9]
> >>print bb
> [0,1,2,3,4,5,6,7,8,9]
> >> # okay, everyth
Python lists are mutable. All mutable objects will behave in the fashion you
described, whereas immutable objects -- tuples, integer, floats, etc. --
will behave in the fashion that you expect.
This is because python keeps references to objects. When you say bb = aa,
you are really saying, "Ta
Keith Suda-Cederquist wrote:
> Hi,
>
> I'm using iPython and I've run into an occasional problem that I don't
> understand. Here is what I'm seeing:
>
> >>aa=range(0,10)
> >>bb=aa
> >>print aa
> [0,1,2,3,4,5,6,7,8,9]
> >>print bb
> [0,1,2,3,4,5,6,7,8,9]
> >> # okay, everything allright at this po
Hi,
I'm using iPython and I've run into an occasional problem that I don't
understand. Here is what I'm seeing:
>>aa=range(0,10)
>>bb=aa
>>print aa
[0,1,2,3,4,5,6,7,8,9]
>>print bb
[0,1,2,3,4,5,6,7,8,9]
>> # okay, everything allright at this point
>>bb[5]=0 #change bb
>>print aa
[0,1,2,3,4,0,6
13 matches
Mail list logo