Great video. Just one point about modifying a mutable object inside an immutable object. In fact, Python only checks if the objects inside an immutable object are changing or not. If you take id() from your list object (which is inside your tuple), then you see the memory address of your list object. If you modify your list object, the id() or memory address does not change (because this is the property of a mutable object). Since the new list object is not different from the original one, Python does not care and in its opinion still the immutability of the tuple object is not violated.
Hi, I have a doubt. We say that the reference to the list doesn't change and hence we can still change the list in a tuple. But why does it stop us in the case of integer? Does the reference change for integers? Sorry I know it sounds stupid bit if you can please clarify it
Surely the non-transitive part benefits runtime performance as python does not have to traverse objects and structures? I actually first noticed Python mutability last year where it stopped me from getting 100% unit tests passing, was a bit of a laughing point when I was done as 5 minutes after I left the interview room I realised what I'd done and made some new rules for the future. On the `cost` side of things in terms of processing speed whilst I'm aware CoW (copy on write) semantics exist in some languages how would you feel about a mnemonic or key-word to make copy or copy on write available to python in a more terse way?)
Why use the word "mutable"? Reminds me too much of muting something, like a television speaker is mutable (you can make it quiet, or change the volume). Why not just use "changeable" and "unchangeable"?
awesome Dan-great clarity-it only gives me a reason to "stalk" { :-)} you on the net-you were crystal clear-im not a programmer by background but dba-ur videos encourages me to take a serious look at python
It was partly useful to me. Much more interesting part would be to expand with an explanation of memory management by mutable and immutable objects, this would make clear that "non-transistent state".
Hi Dan, thanks for putting on this great tutorial series. I tried out and understood the examples here but found the following oddness. I did: list1 = ['a', 'b', 'c'] list2 = ['d', 'e', 'f'] tup1 = ( 42, list1, 'hello') tup1 >(42, ['a', 'b', 'c'], 'hello') tup1.index(list1) >1 then, tup1[1][1] = 'x' tup1 >(42, ['a', 'x', 'c'], 'hello') tup1.index(list1) >1 list1[1] = 'y' list1 >['a', 'y', 'c'] tup1 >(42, ['a', 'y', 'c'], 'hello) # tup1 item[1] still points to the (mutated) list1 tup1.index(list1) >1 also, tup1[1] is list1 >True - so far, as I expected then, list1 = list2 # not sure if this is now a new assignment or a mutation of list1 list1 is list2 >True list1 >['d', 'e', 'f'] tup1 >(42, ['a', 'y', 'c'], 'hello') # still pointing to the previous contents of list1 tup1[1] is list1 >False tup1.index(list1) >ValueError....etc what is tup1[1] now pointing to? it seens no longer pointing at list1 from where is tup1[1] 'getting' ['a', 'y', 'c'] ? is this list item now simply an indepentent tuple item? This surprised me. I was expecting the pointer/link to persist python 3.6.4
Recall tuples are immutable, same way tup1[0] = 40 will throw an error, assigning another list to index 1 will be disallowed. But you can access the list and modify the properties in the list. tup1[1] still points to the object ['a', 'y', 'c'] list1 points to list2's object now
Every immutable object can be easily made mutable and changed then made immutable. Python does not support truly immutable objects that cannot be changed.
![ILLSLICK - WINTER IS COMING [Official Video]](http://i.ytimg.com/vi/dwTMeM1zIhQ/mqdefault.jpg)
wow can i ask what kind of mic you use? the voice is extremely clear
Great video. Just one point about modifying a mutable object inside an immutable object. In fact, Python only checks if the objects inside an immutable object are changing or not. If you take id() from your list object (which is inside your tuple), then you see the memory address of your list object. If you modify your list object, the id() or memory address does not change (because this is the property of a mutable object). Since the new list object is not different from the original one, Python does not care and in its opinion still the immutability of the tuple object is not violated.
thanks, this was helpful
Hi,
I have a doubt. We say that the reference to the list doesn't change and hence we can still change the list in a tuple. But why does it stop us in the case of integer? Does the reference change for integers? Sorry I know it sounds stupid bit if you can please clarify it
An integer is an immutable value. Every time that it changes, a new reference in the memory is created.
Surely the non-transitive part benefits runtime performance as python does not have to traverse objects and structures?
I actually first noticed Python mutability last year where it stopped me from getting 100% unit tests passing, was a bit of a laughing point when I was done as 5 minutes after I left the interview room I realised what I'd done and made some new rules for the future.
On the `cost` side of things in terms of processing speed whilst I'm aware CoW (copy on write) semantics exist in some languages how would you feel about a mnemonic or key-word to make copy or copy on write available to python in a more terse way?)
Thank you! This concept was confusing coming from mainly coding in C.
Check out my TH-cam channel for more on Python
Thanks for your video but I wish you would have done the same for the set because the set does not allow changing mutable elements within the set
Why use the word "mutable"? Reminds me too much of muting something, like a television speaker is mutable (you can make it quiet, or change the volume). Why not just use "changeable" and "unchangeable"?
awesome Dan-great clarity-it only gives me a reason to "stalk" { :-)} you on the net-you were crystal clear-im not a programmer by background but dba-ur videos encourages me to take a serious look at python
Thanks for the kind words!
Does anyone know which interpreter is being used? I'm interested in the as-you-type help feature.
we are saying numeric data type is immutable but if we assign a=5,we can change 5 to 6 ....but why it's saying immutable
Very well done...amazing work man
Thanks for the kind words!
Crystal clear explanation! I just wonder who are those 11 people who disliked this video :)
It was partly useful to me. Much more interesting part would be to expand with an explanation of memory management by mutable and immutable objects, this would make clear that "non-transistent state".
Today this video helped me a lot
U did not mention numbers are immutable too why?? Or i am missing something to understand??
Sir can you make a video on how mutability works by using variable assignment
Check out my TH-cam channel for more on Python tutorials
Thanks, Dan . This was useful
8:15 Can you please explain "we can modify the objects thats the tuple " holds
If a tuple contains a list as one of its elements, we can modify the list itself which is mutable and that change is visible in the tuple.
Very helpful! Thanks!
Hi Dan, thanks for putting on this great tutorial series.
I tried out and understood the examples here but found the following oddness.
I did:
list1 = ['a', 'b', 'c']
list2 = ['d', 'e', 'f']
tup1 = ( 42, list1, 'hello')
tup1
>(42, ['a', 'b', 'c'], 'hello')
tup1.index(list1)
>1
then,
tup1[1][1] = 'x'
tup1
>(42, ['a', 'x', 'c'], 'hello')
tup1.index(list1)
>1
list1[1] = 'y'
list1
>['a', 'y', 'c']
tup1
>(42, ['a', 'y', 'c'], 'hello) # tup1 item[1] still points to the (mutated) list1
tup1.index(list1)
>1
also,
tup1[1] is list1
>True
- so far, as I expected
then,
list1 = list2 # not sure if this is now a new assignment or a mutation of list1
list1 is list2
>True
list1
>['d', 'e', 'f']
tup1
>(42, ['a', 'y', 'c'], 'hello') # still pointing to the previous contents of list1
tup1[1] is list1
>False
tup1.index(list1)
>ValueError....etc
what is tup1[1] now pointing to? it seens no longer pointing at list1
from where is tup1[1] 'getting' ['a', 'y', 'c'] ? is this list item now simply an indepentent tuple item?
This surprised me. I was expecting the pointer/link to persist
python 3.6.4
Recall tuples are immutable, same way tup1[0] = 40 will throw an error, assigning another list to index 1 will be disallowed. But you can access the list and modify the properties in the list.
tup1[1] still points to the object ['a', 'y', 'c']
list1 points to list2's object now
awesome explanation . thank you !
Well explained ..thank you...
Itd be more clear if u could explain with diagrams of memory space and cpu
thanks broooo
what is this color theme?
You deserve my sub
very well explained
Thanks man 🙌
This helped me a lot as i am coming from java..
Thanks u sir i clear abt topic
Great video
Thanks a bunch!!😃
Thank you!!
thank you
very well explained Thank you
You're very welcome!
thanks alot
Awesome 🙌✌️ yeah it's helped
It's not a bug with python, it's a feature.
because list is mutable. is just that simple
even you put a list in a tuple, its still a list.
thanks man. Good video
You're welcome!
Every immutable object can be easily made mutable and changed then made immutable. Python does not support truly immutable objects that cannot be changed.
nice work
Thanks!
nice video
thanx!
thx
object vs instance
Nice!
Thanks!
perfekt