We don't have tuple comprehensions, and this proposal isn't to add them, so this post is edging into off-topic for the thread so feel free to skip it.
On Sat, Oct 16, 2021 at 03:18:20PM -0400, David Mertz, Ph.D. wrote:
Rather, I'm concerned with readability and programmer expectations. Tuples are best used as "records" of heterogeneous but structured data. This is what makes namedtuples such an elegant extension. When I see a collection of tuples, I generally expect each to have the same "shape", such as a string at index 0, a float at index 1, and an int at index 2. If those positions have attribute names, so much the better.
In contrast, lists (and iterators) I expect to contain many things that are "the same" in a duck-type way. I usually want to loop through them and perform the same operation on each (maybe with some switches, but in the same block).
Right-o, the old "heterogeneous tuples versus homogeneous lists" distinction, I remember that from the old 1.5 days. I haven't heard it mentioned for a long time!
That certainly remains a reasonable guideline to make, albeit less so today:
- for structured data, today we have other options such as named tuples (rather than anonymous builtin tuples), SimpleNamespace and Dataclasses, which may be considered closer matches to "record" or "struct" types from other languages;
- lists and tuples now share the same Sequence interface;
- which now justifies treating tuples as "frozen lists", or lists as "mutable tuples".
But I note that this distinction doesn't make unpacking less useful. Here's an example. Suppose I have two data types represented by coordinates, as tuples:
* a point is a 2-tuple (x, y)
* a rectangle is a 4-tuple (left, top, right, bottom).
Then I can construct a rectangle from the coordinates of the top-left and bottom-right points:
rect = (*topleft, *bottomright)
Having a million such similar items is commonplace. Having a million *fields* is non-existent.
I will grant you that having a million items in a tuple is *unusual*, but it takes more than that to make something an anti-pattern. To be an anti-pattern, something must be commonly used as a solution to some problem, while actually being ineffective or counter-productive.