Tuples, what are they: read-only lists or heterogeneous data arrays?

[sismex01 at hebmex.com]

>
> Sorry, but this makes no sense. I entirely support the notion that a
> tuple should be *exactly* like a list, apart from the fact that it is
> immutable, so every read-only list method should be available for
> tuples, too.
> 

But, for many others (myself included), tuples as they are make
perfect sense, in that they are not lists, are not for data
manipulation/querying, but for storage or association.

A tuple is a unit; it's not a collection of it's contents,
it's something else.  So, tuples shouldn't have all of
list's read-only methods and attributes.

>
> It's bad enough to be chided by Lua aficionados because they need just
> one type to do what we do with tuples, lists and dictionaries. ;^) We
> need no more superflous subtleties.
>

"Chided by Lua aficionados"?
"Superfluous Subtleties"?

Sounds like you're trying to make Python more Lua-like. Not to
be insulting or disrespectful, but frankly, Lua stinks.  It's
like Javascript-only-different (argh).

So Lua has a hyper-tuple-array-dictionary-from-hell, wow, nice.
What happens when you need true list semantics?  Or a real
dictionary?  Or you need to index by compound keys (aka, tuples)?

I had a look at Lua a few months ago, I didn't like it one bit.
But then, that's just me.

If "Lua Aficionados" chide you for "playing" with other languages,
maybe the problem isn't the other language, maybe the solution isn't
in mutating Python into Luaython.

>
> And no, list(t).index(x) does not qualify. Neither does
> operator.indexOf() .
>

Well, it does, if you're collecting data inside a tuple,
instead of using a list.

>
> Guido, can't we settle this once and for all?
>

I thought it was already settled.

-gus