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.
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?)
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
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.
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
wow can i ask what kind of mic you use? the voice is extremely clear
Thank you! This concept was confusing coming from mainly coding in C.
Check out my RUclips channel for more on Python
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?)
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.
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"?
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
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!
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".
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 :)
Does anyone know which interpreter is being used? I'm interested in the as-you-type help feature.
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
U did not mention numbers are immutable too why?? Or i am missing something to understand??
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.
Today this video helped me a lot
Thanks, Dan . This was useful
Very helpful! Thanks!
Itd be more clear if u could explain with diagrams of memory space and cpu
awesome explanation . thank you !
Sir can you make a video on how mutability works by using variable assignment
Check out my RUclips channel for more on Python tutorials
Well explained ..thank you...
thanks broooo
very well explained
Thanks man 🙌
This helped me a lot as i am coming from java..
Thanks u sir i clear abt topic
what is this color theme?
Great video
thank you
Thanks a bunch!!😃
You deserve my sub
Thank you!!
thanks alot
very well explained Thank you
You're very welcome!
thanks man. Good video
You're welcome!
thanx!
thx
It's not a bug with python, it's a feature.
Awesome 🙌✌️ yeah it's helped
nice video
nice work
Thanks!
Every immutable object can be easily made mutable and changed then made immutable. Python does not support truly immutable objects that cannot be changed.
because list is mutable. is just that simple
even you put a list in a tuple, its still a list.
object vs instance
Nice!
Thanks!
perfekt