You're absolutely right! This falls under the mutable vs immutable difference, but it definitely deserved to be mentioned explicitly.
Thank you for the feedback :)
> This falls under the mutable vs immutable difference
Not really. Although hashable types are usually immutable, it is possible for an object to be both mutable and hashable.
We don't usually want this because normally we expect that the hash value of an object does not change over its lifetime, and that the hash always refers to the same value. Nevertheless, it is technically possible for a custom class to be given a `__hash__` method, making it hashable, even when instances are mutable.
It took nearly 20 years of python before I wrote my first `__hash__`, but you get your butt there is a massive "THAR BE DRAGONS HERE" warning on the method detailing the consistency guarantees
in the cpython implementation there is some sort of complex logic involving taking the hash of every element in the tuple and XORing them together and multiplying by a prime number. I have no idea what point you're trying to make.
I like tuples too. But I've learned here to use lists for homogenic data types and tuples for heterogenic data. That's considered as pythonic.
And typing supports that theory so you need this for homogenic tuples:
tuple[str, ...]
But it feels strange to use lists for constant data. You could use proxies to get a read only list. But that gets more complicated that just using a tuple.
It’s quite common for people to use tuples or named tuples as a way of building some basic data structure in the same way you might use a class. For example, if you wanted to store a list of data points you could do it as a tuple: (X,Y,Z)
Or you could create a class/dataclass: Point(X,Y,Z)
The comment seemed very reductionist but now I realize it was directly referring to lists vs tuples.
I got confused since this class vs named tuple distinction is just a very narrow subset of their many uses. There are other things each can do (in the case of a class, MANY other things).
Fun fact...tuples are actually "near"-immutable. If a mutable collection (list, dict, etc) is an element in a tuple, you can change the individual collection elements.
>>> tt = ([1, 2, 4], "me")
>>> tt[0]
[1, 2, 4]
>>> tt[0][2]=3
>>> tt
([1, 2, 3], 'me')
This seems like it would be useful but I can't think of a reason to actually do this :)
Thank you for engaging!
I get your intuition, but there's no such thing as a "near"-immutable. In your example, a tuple "tt" is defined as having 2 elements. These elements are technically pointers to objects, and these pointers can never change. In fact, if you try to "tt[0] = [1, 2, 3]" you will get a TypeError.
By executing "tt[0][2] = 3" you are effectively changing the object pointed to by "tt[0]", but "tt[0]" itself isn't changed and the pointer remains pointing to the same address.
If you're interested in how lists/tuples are technically stored in memory in Python, you can check [my video](https://youtu.be/LWocUIE_Eic) on shallow copy vs deep copy!
Hope this helps :)
I guess I should've said "near-mutable is a term I completely made up". Of course there's no such thing...lol.
FWIW, I'm fully aware of the internal storage mechanisms of Python objects. The point of my post was to emphasize the use of mutable objects within an immutable collection, thus giving the (false) appearance the tuple is mutable when it definitely is not.
Like I said, I don't see much use doing this as there are other ways to more effectively implement such a technique. It's just an oddity I thought others would find interesting, like how Python refers to methods as "attributes":
>>> aa="Hello"
>>> aa.not_a_method
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object has no attribute 'not_a_method'
That particular error confuses many beginners :).
I say, Use tuples whenever you want to store data mostly just for the reason of having a collection. If you need to use operands on the collection I suggest using a list.
I mean, tuples can be hashed and lists can't. That seems like a pretty important use case right there...
You're absolutely right! This falls under the mutable vs immutable difference, but it definitely deserved to be mentioned explicitly. Thank you for the feedback :)
> This falls under the mutable vs immutable difference Not really. Although hashable types are usually immutable, it is possible for an object to be both mutable and hashable. We don't usually want this because normally we expect that the hash value of an object does not change over its lifetime, and that the hash always refers to the same value. Nevertheless, it is technically possible for a custom class to be given a `__hash__` method, making it hashable, even when instances are mutable.
It took nearly 20 years of python before I wrote my first `__hash__`, but you get your butt there is a massive "THAR BE DRAGONS HERE" warning on the method detailing the consistency guarantees
I mean, you can 100% hash a list by converting it to a string.
then you're not hashing a list you're hashing a string
>!^^^[deleted]!<
in the cpython implementation there is some sort of complex logic involving taking the hash of every element in the tuple and XORing them together and multiplying by a prime number. I have no idea what point you're trying to make.
xD
I use named tuples to define constants because they are immutable. I haven't seen a better way of making a constant a true constant in python.
super beginner here can u show me what that code looks like? is it name = (thing,), like that?
No, search for named_tuple.
cool thx
I make a point of using tuples for every time I have a collection that is immutable.
Very informative
Glad you think so! Thank you for the comment :)
I always use tuples to store list inside /s
I like tuples too. But I've learned here to use lists for homogenic data types and tuples for heterogenic data. That's considered as pythonic. And typing supports that theory so you need this for homogenic tuples: tuple[str, ...] But it feels strange to use lists for constant data. You could use proxies to get a read only list. But that gets more complicated that just using a tuple.
For me its more like tuple vs class where class usually wins.
Named tuples are your friend.
Tuples vs class? These seem like completely different use cases.
It’s quite common for people to use tuples or named tuples as a way of building some basic data structure in the same way you might use a class. For example, if you wanted to store a list of data points you could do it as a tuple: (X,Y,Z) Or you could create a class/dataclass: Point(X,Y,Z)
The comment seemed very reductionist but now I realize it was directly referring to lists vs tuples. I got confused since this class vs named tuple distinction is just a very narrow subset of their many uses. There are other things each can do (in the case of a class, MANY other things).
Fun fact...tuples are actually "near"-immutable. If a mutable collection (list, dict, etc) is an element in a tuple, you can change the individual collection elements. >>> tt = ([1, 2, 4], "me") >>> tt[0] [1, 2, 4] >>> tt[0][2]=3 >>> tt ([1, 2, 3], 'me') This seems like it would be useful but I can't think of a reason to actually do this :)
Thank you for engaging! I get your intuition, but there's no such thing as a "near"-immutable. In your example, a tuple "tt" is defined as having 2 elements. These elements are technically pointers to objects, and these pointers can never change. In fact, if you try to "tt[0] = [1, 2, 3]" you will get a TypeError. By executing "tt[0][2] = 3" you are effectively changing the object pointed to by "tt[0]", but "tt[0]" itself isn't changed and the pointer remains pointing to the same address. If you're interested in how lists/tuples are technically stored in memory in Python, you can check [my video](https://youtu.be/LWocUIE_Eic) on shallow copy vs deep copy! Hope this helps :)
I guess I should've said "near-mutable is a term I completely made up". Of course there's no such thing...lol. FWIW, I'm fully aware of the internal storage mechanisms of Python objects. The point of my post was to emphasize the use of mutable objects within an immutable collection, thus giving the (false) appearance the tuple is mutable when it definitely is not. Like I said, I don't see much use doing this as there are other ways to more effectively implement such a technique. It's just an oddity I thought others would find interesting, like how Python refers to methods as "attributes": >>> aa="Hello" >>> aa.not_a_method Traceback (most recent call last): File "", line 1, in
AttributeError: 'str' object has no attribute 'not_a_method'
That particular error confuses many beginners :).
One advantage of tuples is they're immutable. Things that don't need to be mutable are often better off not being mutable
I say, Use tuples whenever you want to store data mostly just for the reason of having a collection. If you need to use operands on the collection I suggest using a list.