List vs tuples

[John Roth]

"Isaac To" <kkto at csis.hku.hk> wrote in message
news:7in05lfpqt.fsf at enark.csis.hku.hk...
> >>>>> "John" == John Roth <newsgroups at jhrothjr.com> writes:
>
>     John> It's a common question. A list is a data structure that is
>     John> intended to be used with homogenous members; that is, with
members
>     John> of the same type.
>
> I feel you argument very strange.  Even that it might be the original
> intention, I see nothing in the language that support your argument.

Python is an extremely flexible and dynamic language. There's very
little specialized support for a lot of things. That doesn't mean that
the language designers didn't have that usage in mind.

> In particular, nothing says that tuples cannot be used (or is troublesome
to
> use) when members are of the same type.  And nothing says that lists
cannot
> be used (or is troublesome to use) when members are of different types.

Quite true. So what? Python, by design, does not get in your
way when you try to do strange and absurd things. For some
people in some situations, those things are undoubtedly going
to be the most obvious and reasonable way to approach their
problem.

> If getTime() give you a list instead, then [hours, minute, second] =
> getTime() would still give you the hours, minute and second variables
> assigned.

True. Again, so what? The basic conceptual issue, which
Don Cave explained much better than I did, is that any
subsequence of a list is of the same *conceptual* type as the
list itself. A subset of the fields of a struct is not of the same
conceptual type as the original struct. You cannot take the
third element of that time tuple and claim it is the same type
(a time of day) as the original.

> And you can use a list here as well.  Indeed, if you want to emulate C
> struct, you probably will use list instead of tuples, since in C, structs
> are mutable.

By the time I want to actually change the elements, I'm going
to want a full fledged object where I can refer to the various
elements by name.

As far as I'm concerned, tuples serve a fairly well defined niche.
I don't think they're all that successful a language feature for a
number of reasons, among which are that I much prefer to deal
with struct-like constructs by name, not by index position, and
growing a tuple into an object is a rather messy proposition for
exactly that reason.

The other major issue here is that you seem to be trying
to argue that tuples are unnecessary because lists can do
everything that tuples can, and more (except be used as
keys in dicts, besides they take up more memory and
they're slower.)

I don't buy that line of arguement. A large part of programming
is finding ways of expressing intent in the program so you
don't wonder what you did six months later. Tuples and lists
serve such different conceptual issues that they help expressiveness.

John Roth


>
> Regards,
> Isaac.