On Oct 16, 2019, at 22:13, Kyle Stanley <firstname.lastname@example.org> wrote:
Maybe borrowing a word from a different language—record or datatype or something—would avoid that problem?
Typically there’s a distinction between a record and a tuple—in fact, two distinctions.
A tuple or product type is just the product of the types of its fields. All tuples of a str and an int are the same type, (str, int). Even if you give that type multiple names. For example, if you define file=(str, int) to represent a path and an fd and later define person=(str, int) to represent a name and age, file and person are the same type.
A record type or datatype is a distinct type from all other types, even if they happen to have the same field types. A file(fd: int, path: str) is not the same type as a person(age: int, name: str). Sometimes field names are optional (and a record type with field names is a “proper” record type).
From a quick scan of the Wikipedia article you linked, it appears to agree with this:
A record type is a data type that describes such values and variables. Most modern computer languages allow the programmer to define new record types. The definition includes specifying the data type of each field and an identifier (name or label) by which it can be accessed. In type theory, product types (with no field names) are generally preferred due to their simplicity, but proper record types are studied in languages such as System F-sub.
I’m sure there’s at least one exception that uses “record” to mean a plain product type, but I don’t think any major languages do.
So I don’t think there’s any danger of people expecting Record to include tuples based on analogy with other languages, or type-theory definition, or anything else.
Perhaps something like "associative container" might be more viable? This would apply to any type that could be directly converted to or represented as a dictionary.
Also, what exactly does “could be directly converted to or represented as a dictionary” mean? A namedtuple isn’t stored or represented as a dictionary, and the only way to convert it to a dictionary is by building a dictionary on the fly out of zipping the field names with the values. That’s if anything less direct than a normal class, where you just have to access the instance’s __dict__.
Finally, why are we even bikeshedding this? As Steven already explained, there’s no point in trying to nail down details for something when it’s not even remotely clear what it’s meant to be, or even could be, used for.