You could, but I think mine is better. (firstname, lastname) and (x,y,z) are homogeneous collections. But they probably should be tuples. In a tuple the position describes the structure, in a list the position merely describes the order. Hence why tuples are best if you plan to unpack them (ie. firstname, lastname = name).
Trouble is Python doesn't completely separate the concepts like some languages do (e.g. C array/struct, R array/list). You can unpack lists and store heterogeneous items in them. Many libraries do this (e.g. SQL libraries will give a list per row by default). And if you follow the bash read idiom in Python using str.split you'll unpack a list as well. For me the distinction is about documenting my code.
The only real practical advantage I'm aware of is tuples are hashable. I don't think they are implemented anything like structs underneath.
> (firstname, lastname) and (x,y,z) are homogeneous collections.
Disagree. In a language with a decent type system you would give them different types, because using a first name as a last name or an x as a z is always an error.
Another rule of thumb is that a lot of the time you can make code that uses tuples clearer by rewriting it to use namedtuple-defined struct values. If the language supported it, it'd probably also make sense most of the time to define a type for each tuple field, and have a type-checker look for errors.
Occasionally you see tuples used where they want immutable and hashable lists, but most of the time they're used as shorthand struct/"pod" tours types.
Interesting. I should probably try one of these typed languages. When I was thinking of types I was thinking about "physical" types like in C, not abstract types.
Yeah, it's pretty common to think of types as "representational", and that really doesn't get at most of what they are good for.
Even in C you can get some good help from the type checker if you know how to use it. For instance, see https://dlthomas.github.io/using-c-types-talk/slides/slides.... for a technique that can turn a flakey segfault from misuse of an API into a compile time error (later slides do just that for a simple SDL program, with a modified header file).
Even in C, we could use abstract types more; we could use wrapper structs more, to introduce abstraction where we often idiomatically do not.
(Again about Rust and C++ equally, if we'd only care about "physical" type, the string and the vector would be the same type. The distinct string type allows us to form the rules around exactly what kind of values we allow for or optimize for using that type.)
Trouble is Python doesn't completely separate the concepts like some languages do (e.g. C array/struct, R array/list). You can unpack lists and store heterogeneous items in them. Many libraries do this (e.g. SQL libraries will give a list per row by default). And if you follow the bash read idiom in Python using str.split you'll unpack a list as well. For me the distinction is about documenting my code.
The only real practical advantage I'm aware of is tuples are hashable. I don't think they are implemented anything like structs underneath.