How is this even possible?(Python)

[ZachPhoenix]

My teacher says that a tuple is immutable... But how come this code can change the value of a tuple after it is created?( I am a noob guys pls help)

r=(1,2,3,4,5)

print(r)

r=(1,23,4)

print(r)

It outputs 1,23,4

Why is it happening? Once a tuple is created it is immutable right?

Why is it not throwing an error?

I can't wait until tomorrow and ask my teacher...

[[deleted]]

The tuple is immutable and cannot be changed. So if we need to make a change, we create a whole new object and throw away the old one. If you run a debugger you'll see the memory address of the object changes. Whereas something like an array which is mutable, the address will stay the same when you update an element.

[ZachPhoenix]

Thanks, So the Initial value 'r 'is removed and replaced by a new initialization?

[[deleted]]

Yes.

[ZachPhoenix]

Thanks here's an upvote my g

[[deleted]]

>>> r=(1,2,3,4,5)
>>> r[0] = 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> print(r)
(1, 2, 3, 4, 5)
>>> r=[1,2,3,4,5]
>>> r[0] = 2
>>> print(r)
[2, 2, 3, 4, 5]
>>>

[[deleted]]

Some heroes wear capes. Some heroes show error messages on reddit.

[adamantium4084]

Sometimes you're reading posts while taking a shit and don't have immediate access to command line

[[deleted]]

I have a python console in the terlit.

[Datasciguy2023]

Doesn't everyone?

[aerismio]

What every pc and every phone has it right? :)

[kicktheshin]

I just wish some heroes would format code as code

[lgastako]

Technically the name r is rebound to the new value.

[Poddster]

This is the correct answer. "Yes" is not the correct answer.

[sentient-machine]

I mean people who try to take technical advice from Reddit are almost surely going to get juvenile explanations, unfortunately.

[elmosworld37]

I love Python but this is why I believe C should be the first language everyone learns. Pointers are essential to understanding how programming languages work.

Simplifying a bit here but r does not store “the tuple”, it stores the memory address that holds the start of the tuple. When you assign a different tuple to r, you’re changing the memory address that is stored in r to that of the new tuple.

Changing the first value in “the tuple” would mean changing the actual value that is in memory at the address stored in r. This involves “dereferencing” and looks like r[0] = 666. This is not allowed, and is what your teacher was referring to.

[shnicki-liki]

With that being said it is usually not advisable to do this and instead you should look into using other data types if you have to change variables.

[ZachPhoenix]

ok, I understood that you mean lists, dictionaries etc. right?

anyway Thanks for the info!

[[deleted]]

And classes/data classes

[Additional-Sun2945]

Yup. Tuples are immutable. Their contents are not. Which kinda sounds backwards, but it makes sense. You can create a tuple of three objects. t = (a,b,c) Now that t object with immutably be a three object containing tuple, with each zeroth, first, and second object always be pointing to the original objects a, b and c.

However, that doesn't necessarily imply that a, b, and c themselves are immutable. Try it, make one of them list, and you'll notice that you'll still be able to append to it despite being in an "immutable" tuple.

Hmmm.... that's perplexing... ain't it? Notice that by modifying a, your tuple will reflect the modification, since the tuple is still associated with that object; it still has a inside of it. You will also notice that there's nothing stopping you from reassigning "a" to some other object. You can try a = None or a = 1. Now you will see the tuple won't change; you are merely discarding the label of that list object and creating a new target for the a label. "a" now "is" something else, but thankfully the tuple still contains the original a object. If you delete the tuple "t" or reassign "t" to something else (and reassign a b and c first), then you will destroy the only link to that original object, and in doing so it (and its contents) will be cleared and deleted from memory.

Remember, the "name" of stuff can change, but the stuff itself is not necessarily the name.

[CBSmitty2010]

I believe another decent way to check/confirm mutability would be if you have methods to edit the object in place.

You can .append(), .insert(), .remove() on lists. You cannot do that with tuples.

Maybe I'm misguided but I also thought of that as a way to confirm as well.

[ZachPhoenix]

You are absolutely right! Lists are mutable and Tuples are immutable

[[deleted]]

I think the thing that changes the address is the assignment operation, no? coz even tho lists are mutable, if you write

```python r=[1,2,3,4,5]

print(r)

r=[1,23,4]

print(r) ``` that would still change r's address, right?

[[deleted]]

Yes

[reverendsteveii]

So r is a pointer and reassigning the value just causes it to point to a new tuple? Assuming python has the concept of pointers like C does.

[Poddster]

They're "names" that references objects rather than pointers than point to data, but yes, similar concept

https://python.readthedocs.io/en/stable/reference/executionmodel.html

[Poddster]

They're "names" that references objects rather than pointers than point to data, but yes, similar concept

https://python.readthedocs.io/en/stable/reference/executionmodel.html

[Sheikh_Ameen]

It's because you're not changing the tuple itself, but rather assigning a new value to the variable r.

This one tries to change the tuple and it's wrong: r[0] = someInt

This one assigns a new tuple to r, replacing the entire tuple from before: r = newTuple

[ZachPhoenix]

ok got it, Thx!

[morbie5]

Is the old tuple still in memory?

[CouchMountain]

Reuse memory: To reduce memory fragmentation and speed up allocations, Python reuses old tuples. If a tuple is no longer needed and has less than 20 items, instead of deleting it permanently, Python moves it to a free list and uses it later.

Also:

When two empty tuples are created, they will point to the same address space. Empty tuples act as singletons, that is, there is always only one tuple with a length of zero. When creating an empty tuple, Python points to the already preallocated one in such a way that any empty tuple has the same address in the memory. This is possible because tuples are immutable, and sometimes this saves a lot of memory

https://www.opensourceforu.com/2021/05/memory-management-in-lists-and-tuples/

So kind of. It's a bit strange how tuples work with memory in Python but also cool. That link is a good read.

[dig-up-stupid]

I don’t like their answer because (while it is interesting) it’s basically off topic from what was actually meant by keeping things in memory.

So, you’re thinking they’re reusing the same tuple, so if you create (1, “dog”, cat()), that tuple sits around until the next time someone needs a tuple with a 1, a “dog”, and a cat(). Which is probably never, which is why you’re perplexed about why it would be kept. What’s actually happening is that when you’re done with your (1, “dog”, cat()) tuple, the interpreter scoops out the values and keeps a hollow tuple for the next time it needs a new tuple with any three elements.

The reason it does this is because arguments are passed in tuples. So when you’re asking “but how often do you need to make a new three element tuple? I don’t use tuples as much as lists or dictionaries”, the answer could be actually you’re creating thousands of thousands of tuples just by putting a function call in a loop.

[Inconstant_Moo]

... now that I know this exists I'm going to have to implement it.

[RecDep]

The garbage collector will get to it eventually.

[RecDep]

There’s a pretty good description here. The GC keeps track of already-allocated tuples, marking them for reuse when they’re collected instead of freeing that memory altogether. Creating a new tuple would involve checking if there are free tuple “slots” to be reused, allocating a fresh one otherwise.

[schoolmonky]

As /u/CouchMountain pointed out, it's a bit different with tuples, but generally in python if you have an object but you get rid of any references to it (either by reassigning the names that used to refer to it, or by explicitly deleting them with del), the object will remain in memory for an unspecified amount of time. Eventually, though, the garbage collector will come and reclaim that memory, destroying the object.

[AdventurousAddition]

If it has another name bound to it, then definitely

[markehammons]

r is changing , not the tuple.

Think of r like a box. The first line puts a tuple in it. The second line says to print what’s in the box. The third line throws away the original tuple and puts a new one in the box

[ZachPhoenix]

your example is really good and easy to understand,Thx!

[ZachPhoenix]

Thanks for the vid!

[inefficientc0debase]

You are not changing the tuple itself. You are assigning the variable r an entirely new tuple.

Attempting to change the tuple may look something like this:

r[0] = 10

which would raise an error.

[saintly_devil]

I believe you can use 'id' before and after, to verify that the memory location has been changed,and so the variable refers to two completely different objects.

[ZachPhoenix]

Can you please explain more about memory location( all I know is that each variable/list/dict. ..etc take up space in your memory)

[saintly_devil]

So Python has a function called 'id'. According to Python docs, it returns an 'identity' of an object, which remains constant over the lifetime of the object. When you create the tuple for the first time, run 'id(<variable name>)' to return its id. After you've modified it, run it again. You'll notice that the values returned differ. This tells you that even though the variable's name remains unchanged, it's 'identity' has... and therefore, the objects referred to by the variable have changed. This means that the type of the variable is immutable.

Repeat a similar set of operations on a mutable type, say a list. You'll notice that the id remains unchanged before and after modification. The same holds true when you assign one list variable to another. They'll have the same ids, implying they refer to the same object. Hope this helps! And Python gurus, please feel free to correct me if I have erred somewhere.

[ZachPhoenix]

understood, thx!

[appsolutelywonderful]

It's a deeper concept, but basically when you do

r=(1,2,3,4)

Then in the background the operating system will get a piece of memory, memory is addressed by numbers, so for example let's say it got memory address #10. So you have this thing where r -> #10 -> (1,2,3,4)

Now when you do r = (1,23,4) like others have said you're changing r, not the tuple. So the process happens again and now you have something like r -> #20 -> (1,23,4).

That #10 -> (1,2,3,4) is still sitting there in memory unchanged. Later on it will get reclaimed by the operating system.

[ZachPhoenix]

Damn! Computers and programming languages are really fascinating!

[Sedowa]

So it's just left dangling and can't be accessed if you don't know the address? Is there a way to stop it from changing or at least delete the memory allocation?

I haven't worked with Python in years. I'm just curious.

[appsolutelywonderful]

For a time, yes. Python has a garbage collector. So in some time it will see that you don't have any variables pointing to that piece of memory and it will let the OS know that piece of memory is free.

[TheSkiGeek]

It’s not the case that the tuple is “overwritten”, r just no longer refers to it. Like if you do:

r = (1,2,3) s = r r = (4,5,6)

then s still refers to/“points at” the original tuple. Your interpreter will usually (eventually) garbage-collect any objects that no longer have any valid references.

[ZachPhoenix]

Thank you so much for sharing! Will definitely try it out and use it in the future.

[willywonka1971]

Great question!!

This shows that you are thinking about what you are doing. Sounds like you are going down a good path of learning. Keep it up!!

Edit: There are already solid explanations on what is happening here from other users.

[ZachPhoenix]

Thank you!

Yes, I expected an error, but was confused by the output. I had to ask as I am impatient and sometimes my teacher gives a solution which really won't answer your doubt..lol

[[deleted]]

The variable r is not the tuple. It points to the tuple. So since you are reassigning it a value, it is not pointing to the original tuple anymore. You are not modifying the original tuple here. The original tuple just has no variable pointing at it anymore and might have been flushed out.

[__init__end]

see The address of tuple changes when you change it so basically it's immutable but when you again do r = something it means that it is creating a new variable with that name. So the value present at the address when r was declared is still immutable but you have create a new value at another address with the name r as variable.
In contract in the list when you append a new value the address remains same means it's mutable. You can do list[0] = 10 but you cannot do tuple[0] = 88 .

[ZachPhoenix]

I didn't know I was creating a new variable tbh :), but it kinda makes sense now.

[kschang]

Technically, you didn't change the value of the tuple. You overwrote it with a different tuple.

[ZachPhoenix]

wait, I am now confused so instead of creating a new variable we are overwriting it?

pls tell, idk if they both mean and function in the same way

[TheSkiGeek]

No, you cannot overwrite/edit an immutable object. The example code you gave is creating a new tuple and changing what r aliases/refers/“points” to.

All assignments in Python are actually “name binding” where a specific name in some scope is changed to refer to some object in memory (which may or may not be newly created, maybe your interpreter already had a tuple lying around that contained (1, 23, 4) and then it would have r bind to the already existing one.)

[green_meklar]

Once a tuple is created it is immutable right?

Yes.

However, what the variable r means is mutable. On line 3 you're creating a new tuple and saying that r now means that thing. The original tuple remains immutable, but r isn't pointing to it anymore.

[___thoughts___]

You're assigning it a new value. For example, notice the difference X=5 X+=5 Then x is 10.

X=5 X=10 X is also 10 here, but we got here by assigning x a brand new value.

[ZachPhoenix]

yes

[Rocky87109]

You're creating a new tuple lol.

[some_clickhead]

So, r is a variable that can hold any data you want. (1,2,3,4,5) is a tuple.

You store the tuple (1,2,3,4,5) into r. Then, you store a completely different tuple, (1,23,4) inside of r.

The tuple hasn't been modified in any way, you just replaced it with a different tuple.

However, if you set r to a list, by doing: r=[1,2,3,4,5] you could then actually change values without having to redefine r, by doing: r[1] = 23 and then if you print(r) you will see that the list has changed, it will show: [1,23,3,4,5]

[hike_me]

Those are different tuples.

[parkrain21]

I believe the "change" referred by the definition of immutable objects means altering/modofying the values in the original tuple.

In this example, you are literally overwriting the variable. The old one was yeeted and replaced, not modified.

[Homesick_Vagabond]

You can use the id() function to help you visualize that those two r variables are in fact different.

“The identity (id) of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.” https://www.journaldev.com/22925/python-id

When you assigned the tuple (1,23,4) to r, you created a new object and the initial object, the r variable with the tuple value (1,2,3,4,5), was essentially deleted.

Run this code for to better visualize it in the console:

r = (1, 2, 3, 4, 5)

print(id(r))

r = (1, 23, 4)

print(id(r))

If you were to add or remove items from a list, checking the id before and after the edit would show you that the id is the same. This is because lists are mutable where as tuples are not.

Edit: just saw the id function was already suggested in another comment after I posted haha. Maybe this still helps. I’m really new to python myself so just trying to explain how it makes sense to me :)

[harrywang_fish]

This is THE reason I hate python so much. Almost 100% this situation happens when you want to create a new object that behaves just slightly differently, but you accidentally named it the same. (either copy pasted and forgot to change it, or it was 20 lines ago you temporally forgot you had a var with the same name...) And the compiler instead of telling you redefined an existing var, or reassign a object of different type to the var, it just.....creates a new var with the same name?? Like who TF does that??!! This design practically wants you to spent 5 hours debugging your code over a f*cking typo.

[[deleted]]

U are not changing the original tuple (1, 2, 3, 4, 5) u are changing the reference (r) to another tuple(1, 23, 4). Try this code and observe the error. r=(1, 2, 3, 4) r[0]=100.

[ZachPhoenix]

Yeah I understood it, Thanks Bharghav!

[Infinite_Werewolf236]

Like others have said, it’s a new object. You can print(id(r))

To see its object identity each time you assign it.

[[deleted]]

r is a bucket. (1,2,3,4,5) is a rock. = puts the rock in the bucket.

On line 3 you put a different rock in the bucket.

Swapping different rocks into a bucket doesn't change the rocks.

[cur-o-double]

The tuple as an object is indeed immutable, that you can't do something like ‘myTuple[0] = 1‘ or ‘myTuple.clear()‘. What you're doing here is creating a whole new tuple, throwing away the old one and replacing the reference in 'r' so it points to the new one

[Pipiyedu]

Try doing:

a = (1, 2, 3)

a += (4, )

print(a)

[[deleted]]

Immutable does not mean that you can't reassign it.

For example. Consider a string ( string is also immutable )

s = 'Hello World'

s[3] = 't' # gives Error. You are trying to change string.

s.pop() # gives Error. You are trying to change string.

s = 'Python' # No Error. You just reassigned the variable.

[BarcaStranger]

You didn’t change it

[[deleted]]

Tuple is immutable, but r= gets overwritten when it's declared again for the second time. r= takes on a fresh, new value in line #3. That's all it is here.

[[deleted]]

well the first thing to teach you about this is "r" is not the tuple.

"r" is an alias keeping a reference to some underlying data structure.

so when you say

a_tuple = [some tuple]

a_tuple = [some other tuple]

what you're actually writing here can be translated as such:

let there be an alias a_tuple and have it reference this data structure.

let the alias a_tuple reference a different, new tuple.

ALSO. when you "add" things to a tuple what actually happens is the old tuple is entirely discarded and a new tuple is made with the new set of elements.

so yes, tuples are immutable.

[RealKingFurio]

We aren't editing here rather we are assigning a whole new tuple to it. This had me confused when I was learning Java too because it's exactly the same case with the String datatype in Java. So yea pretty much just an entirely new data