why tuple instead of list

[Skaperen]

sounds like a language design issue. but we're stuck with it, now. ok, this argument makes sense, though my adict class would be another way to do it.

[perfringo]

Just some history:

Python’s major data types also derive from ABC, though with some modifications. ABC’s lists were really bags or multisets, which were always kept sorted using a modified B-tree implementation. Its tables were associative arrays that were similarly kept sorted by key. I found that neither data type was suitable to represent, for example, the sequence of lines read from a file, which I anticipated would be a common use case. (In ABC you'd have to use a table with the line numbers as keys, but that complicates insertions and deletions.) So I changed the list type into a flexible array with insert and delete operations, giving users complete control over the ordering of items in a list. A sort method supported the occasional need for sorted results.

I also replaced the sorted tables with a hash table implementation. I chose a hash table because I believed this to be faster and easier to implement than ABC’s B-tree implementation. The latter was theoretically proven to be asymptotically optimal in space and time consumption for a wide variety of operations, but in practice it had turned out to be difficult to implement correctly due to the complexity of the B-tree algorithms. For the same reason, the performance was also sub-optimal for small table sizes.

I kept ABC’s immutable tuple data type--Python’s tuple packing and unpacking operations are taken directly from ABC. Since tuples are internally represented by arrays, I decided to add array-like indexing and slicing.

One consequence of adding an array-like interface to tuples is that I had to figure out some way to resolve the edge cases of tuples with length 0 or 1. One of the rules I took from ABC was that every data type, when printed or converted to a string, should be represented by an expression that was a valid input to the language’s parser. So, it followed that I needed to have notations for 0- and 1-length tuples. At the same time I didn’t want to lose the distinction between a one-tuple and a bare parenthesized expression, so I settled for an ugly but pragmatic approach where a trailing comma would turn an expression into a one-tuple and "()" would represent a zero-tuple. It's worth nothing that parentheses aren’t normally required by Python’s tuple syntax, except here--I felt representing the empty tuple by “nothing” could too easily mask genuine typos.

My five cents: lists are used for items of same datatype and tuples for items of different datatypes. Tuples are like records (rows) in database which can have different datatypes in different columns and their order matter.

[Skaperen]

the language i was designing before i encountered Python (i never encountered ABC) did not have distinctive types for mutable vs immutable. what it had was the ability to change any data object instance to immutable, either temporarily (can be undone) or permanently (cannot be undone). simple literals were automatically made permanently immutable. container literals were not. but you could build a mutable string or list from their creation methods. i had not done any unicode support in my language, though. if, for some reason, i were to finish it today, unicode, and many other things inspired my Python and Python3 would be added on.