2 ms·

> Because tuples cannot change over time, they are (slightly) faster to create compared to lists. Like you mentioned, they are being created just to be iterated

by _dain_ 4y ago

> Because tuples cannot change over time, they are (slightly) faster to create compared to lists. Like you mentioned, they are being created just to be iterated over. It is a small enough of a performance improvement that it more of a style choice then anything. But that's just wrong. Tuples are not just immutable lists. They're for heterogeneous collections and are meant to be destructured or otherwise have their elements acted on individually. Lists are for homogeneous collections and they're meant to be looped over. Immutability is neither here nor there. The performance benefit is negligible and irrelevant. If you don't believe me, look at how type hints work: an arbitrary-length list of integers is typed like `list[int]`, but you have to write an arbitrary-length tuple of integers like `tuple[int, ...]`. It looks different -- why? Because the way you're meant to use tuples is like `tuple[int, int, str, datetime]`, where there's a fixed number of elements and each one has a distinct meaning, where it usually doesn't make sense to loop over and treat them the same. It's also why there's list comprehension but no tuple comprehension. The suggestion in the example is just plain incorrect.

vharuck 4y ago
>But that's just wrong. Tuples are not just immutable lists. They're for heterogeneous collections and are meant to be destructured or otherwise have their elements acted on individually. Lists are for homogeneous collections and they're meant to be looped over. Immutability is neither here nor there. The performance benefit is negligible and irrelevant. I've never read this opinion before, so I don't think it was intended from the get-go or became a commonly adopted standard. I can see some sense to it, though. But lists aren't just for looping. They often get looped over, but that's true for any collection, even dictionaries. >It's also why there's list comprehension but no tuple comprehension. That's because (x for x in y) was chosen for making generators. Just stick tuple in front and you've got a tuple comprehension.
- _dain_ 4y ago
  It's in the official documentation: https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html >Tuples are immutable sequences, typically used to store collections of heterogeneous data (such as the 2-tuples produced by the enumerate() built-in). Tuples are also used for cases where an immutable sequence of homogeneous data is needed (such as allowing storage in a set or dict instance). GvR email from 2003: https://mail.python.org/pipermail/python-dev/2003-March/033964.html https://mail.python.org/pipermail/python-dev/2003-March/0339... >Tuples are for heterogeneous data, list are for homogeneous data. >Tuples are not read-only lists. Immutable sequence is a use-case, but it's a secondary use-case. The primary use-case is for record-type data. >But lists aren't just for looping. They often get looped over, but that's true for any collection, even dictionaries. My point was more that tuples are not primarily suited for looping over, not that lists exclusively are. >That's because (x for x in y) was chosen for making generators. Just stick tuple in front and you've got a tuple comprehension. But list comprehensions were in the language for several years before generators came around. There was a time when [x for x in foo] worked but (x for x in foo) was a syntax error. Why didn't they make it a tuple at the time? Because that's not what tuples are for. If you look at everywhere tuples show up in the standard library, it's almost always in some context where looping over the collection is not a primary consideration. The clearest example of this dichotomy is in the string methods: the str.split method gives you a list of strings, because the result can be of arbitrary length and you're likely going to loop over it. But str.partition gives a tuple because there are always exactly 3 elements in the result and you're meant to destructure it.
  - dragonwriter 4y ago
    Note that the current official documentation (which you cite), unlike Guido’s 2003 email (which you also cite), explicitly supports tuples as both heterogenous records and immutable homogenous sequences.
dragonwriter 4y ago
> Tuples are not just immutable lists They aren’t just immutable lists logically, but since Python (while it can use a static typechecker for verifying correctness to some extent) doesn’t use type information about what is stored in containers for storage implementation, effectively at runtime they are just immutable lists. But, even logically, and apart from that implementation consideration, immutable lists are one of the things they are, are intended to be, ans are designed to be used for. > They're for heterogeneous collections and are meant to be destructured or otherwise have their elements acted on individually. That is another use case, yes. The existence of that use case does not negate the immutable list use case. > It looks different -- why? tuple type hints have a form (that you point out) for homogenous arbitrary length immutable lists as well as one for fixed-length potentially-heterogenous ordered collections because tuples are intended to serve both purposes, not just the latter. > It's also why there's list comprehension but no tuple comprehension. No, genexps using () and having broader utility is why there are no tuple comprehensions. Heck, if genexps were around first, we might not have list, set, or dictionary comprehensions, either.

by _dain_ 4y ago

vharuck 4y ago

>But that's just wrong. Tuples are not just immutable lists. They're for heterogeneous collections and are meant to be destructured or otherwise have their elements acted on individually. Lists are for homogeneous collections and they're meant to be looped over. Immutability is neither here nor there. The performance benefit is negligible and irrelevant. I've never read this opinion before, so I don't think it was intended from the get-go or became a commonly adopted standard. I can see some sense to it, though. But lists aren't just for looping. They often get looped over, but that's true for any collection, even dictionaries. >It's also why there's list comprehension but no tuple comprehension. That's because (x for x in y) was chosen for making generators. Just stick tuple in front and you've got a tuple comprehension.

_dain_ 4y ago
It's in the official documentation: https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html >Tuples are immutable sequences, typically used to store collections of heterogeneous data (such as the 2-tuples produced by the enumerate() built-in). Tuples are also used for cases where an immutable sequence of homogeneous data is needed (such as allowing storage in a set or dict instance). GvR email from 2003: https://mail.python.org/pipermail/python-dev/2003-March/033964.html https://mail.python.org/pipermail/python-dev/2003-March/0339... >Tuples are for heterogeneous data, list are for homogeneous data. >Tuples are not read-only lists. Immutable sequence is a use-case, but it's a secondary use-case. The primary use-case is for record-type data. >But lists aren't just for looping. They often get looped over, but that's true for any collection, even dictionaries. My point was more that tuples are not primarily suited for looping over, not that lists exclusively are. >That's because (x for x in y) was chosen for making generators. Just stick tuple in front and you've got a tuple comprehension. But list comprehensions were in the language for several years before generators came around. There was a time when [x for x in foo] worked but (x for x in foo) was a syntax error. Why didn't they make it a tuple at the time? Because that's not what tuples are for. If you look at everywhere tuples show up in the standard library, it's almost always in some context where looping over the collection is not a primary consideration. The clearest example of this dichotomy is in the string methods: the str.split method gives you a list of strings, because the result can be of arbitrary length and you're likely going to loop over it. But str.partition gives a tuple because there are always exactly 3 elements in the result and you're meant to destructure it.
- dragonwriter 4y ago
  Note that the current official documentation (which you cite), unlike Guido’s 2003 email (which you also cite), explicitly supports tuples as both heterogenous records and immutable homogenous sequences.

dragonwriter 4y ago

> Tuples are not just immutable lists They aren’t just immutable lists logically, but since Python (while it can use a static typechecker for verifying correctness to some extent) doesn’t use type information about what is stored in containers for storage implementation, effectively at runtime they are just immutable lists. But, even logically, and apart from that implementation consideration, immutable lists are one of the things they are, are intended to be, ans are designed to be used for. > They're for heterogeneous collections and are meant to be destructured or otherwise have their elements acted on individually. That is another use case, yes. The existence of that use case does not negate the immutable list use case. > It looks different -- why? tuple type hints have a form (that you point out) for homogenous arbitrary length immutable lists as well as one for fixed-length potentially-heterogenous ordered collections because tuples are intended to serve both purposes, not just the latter. > It's also why there's list comprehension but no tuple comprehension. No, genexps using () and having broader utility is why there are no tuple comprehensions. Heck, if genexps were around first, we might not have list, set, or dictionary comprehensions, either.