Python Lists vs. Tuples
So, I&#x27;ve long since argued the importance of what Ned terms the &quot;cultural difference&quot;, or the difference between dynamic homogeneous structures (lists&#x2F;relational columns), and static heterogeneous structures (tuples&#x2F;relational rows).  There are important performance ramifications regarding the use of one or the other, and conflating the two (i.e. dynamic heterogeneous) is a strong design smell.  Some languages &quot;get it&quot;, others don&#x27;t.<p>Python is <i>not</i> a language that &quot;gets it&quot;, despite the article&#x27;s examples.  Python chooses the much-less-useful distinction between &quot;immutable sequence&quot; and &quot;mutable sequence&quot;; the lack of any other distinction is borne out by the standard library (as dozzie points out here [1]).  Furthermore, the issue of immutable vs. mutable is <i>totally orthogonal</i> to that of dynamic&#x2F;static and homogeneous&#x2F;heterogeneous.  There&#x27;s no reason that &quot;cultural&quot; lists need be mutable, or &quot;cultural&quot; tuples need be immutable.  So Python&#x27;s choice doesn&#x27;t make sense from this angle either.<p>For example, OCaml has both immutable lists and immutable tuples; its type system enforces exactly the &quot;cultural difference&quot;.  Similarly with C, which has both mutable lists (arrays) and mutable tuples (structs), both of which can be rendered immutable (const).  Why Python chose lists (and only lists!) to have both immutable and mutable flavors, with otherwise identical semantics, is beyond me.<p>Erlang used to &quot;get it&quot;, but they lost the thread when they came out with heterogeneous syntax support for a homogeneous structure (map).  TLA+ totally conflates tuples with lists, but its type system is rich enough to enforce the difference (and as a bonus, allows for the elusive static homogeneous structure).<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12323849" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12323849</a>