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