Tuples -- who needs 'em

[Alexander, Bob]

m.faassen at vet.uu.nl [mailto:m.faassen at vet.uu.nl] wrote:
> 
> Bob Alexander <bobalex at home.com> wrote:
> > I agree with this, too (noting Lisp as possibly the worst example --
> > although a fine language with clear favorable influences on 
> Python). But
> > my issue is not about syntax.
> 
> > However, too bad about that nasty syntax irregularity that 
> using parens for
> > tuples presents  (1,)  (Couldn't resist  ;-)

BTW, a couple of folks pointer out my error in associating the parentheses
with tuple syntax. The parens aren't really part of the syntax, although
they are often used for grouping and visual distinction. However the
dangling comma, as we well know, is always need for one-element tuples.

> But tuples are nice in particular for their *syntax*. With tuples, you
> can do:
> 
> def foo():
>     return 1, 2, 3, 4
> 
> first, second, third, fourth = foo()
> 
> I think this is nice syntax. Without tuples it'd not be as 
> nice. It's not
> so much about efficiency. This pattern occurs all over Python.

I like that syntax too. If tuples and lists were unified, that bracket-free
syntax could also be used for the list/tuple datatype, and nice syntax you
mention would not change.

> [snip]
> > Yet the concept of array is pretty fundamental to 
> programming. Arrays are
> > usually thought of as mutable. Anyone having trouble with 
> that concept is
> > pre-beginner  :-)
> 
> Anyone having trouble with the concept of immutable lists 
> must have never
> heard of functional programming?
> 
> [snip]
> > I'm sure tuples are not an acciental feature. And my issue 
> comes from
> > understanding, not lack of understanding.
> 
> Given the above two items, I don't think you understand tuples yet. I
> consider tuples to be mostly nice syntax (with one nit, the 
> single element
> tuple). You could almost see the immutability semantics being there to
> support the syntax, not the other way around. It might be 
> possible to preserve
> the nice syntax and still get rid of tuples, if you still allow this:
> 
> foo, bar, baz = [1, 2, 3]
> 
> But this is less symmetrical, and since lists are mutable, 
> this may go wrong
> far more easily.

I am wondering where the serious concern about mutable lists comes from, as
it is a pattern in the responses I've gotten on this topic. For me, the
immutable list is a relatively new concept, since I can't think of many
other languages that have it. I'm a programming-language-design kind of
person, and I never really saw mutable lists as a problem that needed
solving. I've used many Python-type languages that have mutable lists but
not immutable ones, and if I don't want the elements to change they don't
change -- I simply avoid the x[i] = y construct :-) And I still haven't
heard from anyone about why there isn't similar concern about immutable
dictionaries.

Anyway, it seems to me that most of the tuple advantages we enjoy could and
should still exist with a merged tuple-list type, and the only possible
drawback is the loss of an immutable sequence type. The gain, though, is one
less decision that we must frequently make (between tuple and list) while
programming.

-- Bob