Lists and Tuples

[Douglas Alan]

Douglas Alan wrote:

I'm never dead wrong.

You were dead wrong to insult me in a debate over subtle programming
aesthetics, where my opinion is just as well-founded as anyone's.

Guido van Rossum, "State of the Python Union", March 2003:
http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt

...

+ It's a matter of user education

+ Example: lists vs. tuples

this is often misrepresented as "tuple are readonly lists",
which is *wrong*

use cases are quite different

*but*... tuples also usable as readonly lists

...

(0) I would never say that a tuple is a read-only list because a tuple
*isn't* a list. I would say that a tuple is an "immutable
sequence", which is true by definition. The use-cases for mutable
sequences and for immutable sequences are obviously quite
different because in one case you are likely going to mutate the
sequence and in the other case, you clearly are not.

(1) Just because Guido asserts it doesn't make it true.

(2) Guido's own brother Just disagrees with him, proving that it isn't
obvious even if you are Dutch.

(3) Guido apparently disagreed with himself when he made the container
for excess arguments be a tuple.

(4) I have quite a few books on Python, and none of them assert that
tuples should only be used as records, and I have seen numerous
examples of decent code that use tuples as full-fledged immutable
sequences to good purpose. I posted such an example from Pmw in
my previous message.

(5) I have never seen a *single* good reason presented anywhere for
restricting oneself to using tuples only as records. I have only
seen it stated as bold assertion without support.

I expect an apology.

Ha! The noive of some people!

|>oug

 

[Douglas Alan]

To me, it's a distinction without a difference. Tuples
*act* like immutable sequences, and I use them that way. I
don't know, though, that I won't get caught some day.

You'll be fine. The only thing you have to watch out for is that some
rude folks here might call you names.

|>oug

 

[Skip Montanaro]

Roy> That's a good example, because it makes for a nice segue. If you
Roy> were holding data from a form that looked like:

Roy> Street: ___________________________
Roy> City: ___________________________
Roy> State: ___________________________
Roy> Zip: ___________________________

Roy> Then I agree you're looking at a 4-tuple (assuming you didn't want
Roy> to go whole-hog and define an Address class). But, imagine a
Roy> somewhat more generic form that looked like:

Roy> Address line 1: ________________________
Roy> Address line 2: ________________________
Roy> Address line 3: ________________________
Roy> Address line 4: ________________________

Roy> You might fill in exactly the same data, but now if feels like it
Roy> should be a list.

I think you're thinking too hard. ;-) What about:

Street 1: ___________________________
Street 2: ___________________________
Street 3: ___________________________
City: ___________________________
State: ___________________________
Zip: ___________________________

? I might use a tuple containing a list. Of course, in some situations,
the "natural form" your data takes has other external influences. If I was
storing addresses in a SQL table I might use a tuple of five strings (one
per column in the database) and just suffer with the fact that I couldn't
have more than three street elements. If addresses were stored in a pickle
file, I'd might go with a tuple containing a list and three strings.

have-we-completely-snowed-the-OP-yet?-ly, y'rs,

Skip

 

[Arthur]

I'm never dead wrong.

Guido van Rossum, "State of the Python Union", March 2003:
http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt

...

+ It's a matter of user education

+ Example: lists vs. tuples

this is often misrepresented as "tuple are readonly lists",
which is *wrong*

use cases are quite different

*but*... tuples also usable as readonly lists

...

I expect an apology.

</F>

I should know better than to have anything to say here. But I did
once start a thread on this subject, having been confused a) by the
questions being addressed here and b) specifically by a definitive
statement Guido had made on the subject.

And was surprised - I admit pleasantly - that some folks with
recognizable names in the commumity, and close to Guido, commented
that Guido's take on this subject were his own. And there were other
views, as well.

And then there was discussion that certainly helped me understand what
it was that Guido meant. And the discussion was helpful, to me.

But am surprised to see a point trumped here, simply by quoting Guido.

Art

 

[Jeff Wagner]

Roy> That's a good example, because it makes for a nice segue. If you
Roy> were holding data from a form that looked like:

Roy> Street: ___________________________
Roy> City: ___________________________
Roy> State: ___________________________
Roy> Zip: ___________________________

Roy> Then I agree you're looking at a 4-tuple (assuming you didn't want
Roy> to go whole-hog and define an Address class). But, imagine a
Roy> somewhat more generic form that looked like:

Roy> Address line 1: ________________________
Roy> Address line 2: ________________________
Roy> Address line 3: ________________________
Roy> Address line 4: ________________________

Roy> You might fill in exactly the same data, but now if feels like it
Roy> should be a list.

I think you're thinking too hard. ;-) What about:

Street 1: ___________________________
Street 2: ___________________________
Street 3: ___________________________
City: ___________________________
State: ___________________________
Zip: ___________________________

? I might use a tuple containing a list. Of course, in some situations,
the "natural form" your data takes has other external influences. If I was
storing addresses in a SQL table I might use a tuple of five strings (one
per column in the database) and just suffer with the fact that I couldn't
have more than three street elements. If addresses were stored in a pickle
file, I'd might go with a tuple containing a list and three strings.

have-we-completely-snowed-the-OP-yet?-ly, y'rs,

Skip

Yes but I'm enjoying it and learning a lot

Jeff

 

[Peter Hansen]

I'm never dead wrong.

[snip]

I should know better than to have anything to say here. [snip]
But am surprised to see a point trumped here, simply by quoting Guido.

"Simply" being the operative word, or perhaps "trumped"... I think
you're missing context, which was an apparent(*) claim that point of view
A was _universally correct_ while B was "dead wrong". By referring
the Guido's comment, I believe Fredrik was "simply" indicating that
he couldn't have been "dead wrong" by any usual definition of that
term, as at least one other person (perhaps only coincidentally
the BDFL) shared the same view.

-Peter

(*) As was clarified later, the "dead wrong" comment was actually
intended to be a sort of rudeness objection, and not at all a
contradiction of the B point of view, as it appeared to be.

 

[sdd]

I've spent most of the day playing around with lists and tuples to get a really good grasp on what
you can do with them. I am still left with a question and that is, when should you choose a list or
a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it
than just that. Everything I tried with a list worked the same with a tuple. So, what's the
difference and why choose one over the other?

Jeff

Here's the biggie:

association = {}
somevals = 1,2,6,'a'
association[somevals] = 13

vs.

association = {}
somevals = [1,2,6,'a']
association[somevals] = 13

-Scott David Daniels
(e-mail address removed)

 

[Ron Adam]

What's the difference?

Items in lists and not in tuples:

Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert',
'__setslice__', 'count', 'remove', '__setitem__', '__iadd__', 'pop',
'__delitem__', 'append', '__imul__'])



-Andrew.

And Items in tuples and not in lists:
Set(['__getnewargs__'])



Items in both tuples and lists:
Set(['__getslice__', '__str__', '__getattribute__', '__rmul__',
'__lt__', '__init__', '__setattr__', '__reduce_ex__', '__new__',
'__contains__', '__class__', '__doc__', '__len__', '__mul__',
'__ne__', '__getitem__', '__reduce__', '__iter__', '__add__',
'__gt__', '__eq__', '__delattr__', '__le__', '__repr__', '__hash__',
'__ge__'])



Maybe someone could tell me how and/or when __getnewargs__ is used?


_Ronald Adam

 

[Colin J. Williams]

I've spent most of the day playing around with lists and tuples to
get a really good grasp on what you can do with them. I am still
left with a question and that is, when should you choose a list or a
tuple? I understand that a tuple is immutable and a list is mutable
but there has to be more to it than just that. Everything I tried
with a list worked the same with a tuple. So, what's the difference
and why choose one over the other?

Try this with a list:

a = [1, 2, 3, 4, 5]
a[3] = 27
print a

Then try it with a tuple.

That's because a tuple is immutable and a list is mutable but what else? I guess I said everything I
tried with a tuple worked with a list ... not mentioning I didn't try to break the immutable/mutable
rule I was aware of. Besides trying to change a tuple, I could cut it, slice and dice it just like I
could a list. They seemed to have the same built-in methods, too.

From what I can see, there is no reason for me to ever want to use a tuple and I think there is
something I am missing. Why would Guido go to all the effort to include tuples if (as it appears)
lists are just as good but more powerful ... you can change the contents of a list.

Should you wish to use a sequence as the key for a dictionary, then a
tuple would be the choice.

Colin W.

 

[Fredrik Lundh]

Maybe someone could tell me how and/or when __getnewargs__ is used?

PEP 307 ("Extensions to the pickle protocol") might be somewhat
helpful:

http://www.python.org/peps/pep-0307.html

</F>

 

[Fredrik Lundh]

You were dead wrong to insult me in a debate over subtle programming
aesthetics, where my opinion is just as well-founded as anyone's.

I actually had to dig up the thread that has caused you such grief
over the years.

as expected, you spent that thread attacking everyone who dis-
agreed with you, misrepresented other people's arguments, referred
to implementation artifacts and design mistakes as "proof", and used
the same muddled thinking as you've shown in this thread. heck,
Tim even introduced the term "douglas-sequences" in contrast to
"python-sequences" in order to make any sense of what you were
arguing about that time. not the kind of behaviour I'd expect from
anyone who wants to be taken seriously.

two years later, you haven't learned a thing; that's pretty tragic.

</F>

 

[Arthur]

Generally, choose between tuples and lists based upon your data. In
situations where you have a small, fixed collection of objects of possibly
differing types, use a tuple. In situations where have a collection of
objects of uniform type which might grow or shrink, use a list. For
example, an address might best be represented as a tuple:

itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201")
caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866")

Though all elements are actually strings, they are conceptually different
types. It probably makes no sense to define itcs as

Some of my confusion derived from these semantic issues. We are
strongly typed and when the list/tuple distinction starts to be talked
with the words "types"," homogenous" , "heterogenous" in close
proximity - we, on the receiving end, will ....

I think the potential misdriection is obvious from your explanation
above.

"Type" is not normally an ambiguous word. It seems to me that an
explanation would stress, upfront, that in fact
homogenous.hetereogenous in this context is at an abstract level, and
unrelated to type,as such and as your example illustrates.

Or else, why does the word "type" need to occur at all, other than
perhaps to explain, explicitily, it is not of relevance

Rather than in a way that implies that it is.

This is a question really. Though not properly phrased as one. Because
I fear I am still missing something.


Art

 

[Fredrik Lundh]

"Type" is not normally an ambiguous word.

really? in my experience, "type" and "object" are about as ambiguous
as words can get, especially when you're talking about Python.

</F>

 

[Arthur]

really? in my experience, "type" and "object" are about as ambiguous
as words can get, especially when you're talking about Python.

</F>

I am sure you are right. On faith. Though its not particularly
helpful.

Art

 

[Arthur]

I am sure you are right. On faith. Though its not particularly
helpful.

Art

Or else I can rephrase my question.

Having learned that type and object are highly ambiguous words, why do
we would tend to use them when wanting to clarify list/tuple
distinctions.

Art

 

[Douglas Alan]

as expected, you spent that thread attacking everyone who dis-
agreed with you, misrepresented other people's arguments, referred
to implementation artifacts and design mistakes as "proof", and used
the same muddled thinking as you've shown in this thread. heck,
Tim even introduced the term "douglas-sequences" in contrast to
"python-sequences" in order to make any sense of what you were
arguing about that time. not the kind of behaviour I'd expect from
anyone who wants to be taken seriously.

Your characterization of the past debate is not only a self-serving
caricature, but it is disingenuous as well. I never attacked or
misrepresented anyone -- I merely disagreed with them. Only you
attacked anyone, Fredrik. As you chose to do again. And
misrepresent.

two years later, you haven't learned a thing; that's pretty tragic.

And you still resort to insults, rather than reason. Yes, tragic,
especially for someone who is apparently an icon of the Python
community.

And speaking of "proof" for one's point -- you never provided a single
iota of evidence, much less proof, for the idea that tuples should
only be used as records, except for that you and Guido say so.

|>oug

 

[Aahz]

really? in my experience, "type" and "object" are about as ambiguous
as words can get, especially when you're talking about Python.

Hrm. I see your point, but I also think it's fairly easy to get people
to agree on definitions for "type" and "object" within the context of a
discussion. From my POV, the ambiguity comes from layering on additional
meanings beyond that supported by the C API.

 

[Fredrik Lundh]

From my POV, the ambiguity comes from layering on additional
meanings beyond that supported by the C API.

what C API? (duck)

 

[Joe Francia]

as expected, you spent that thread attacking everyone who dis-
agreed with you, misrepresented other people's arguments, referred
to implementation artifacts and design mistakes as "proof", and used
the same muddled thinking as you've shown in this thread. <snip>

So you're saying he's a news commentator for Fox News? ;>)

 

[Donn Cave]

Quoth Arthur <[email protected]>:
| On Fri, 5 Dec 2003 11:10:34 -0600, Skip Montanaro <[email protected]>
| wrote:
|> Generally, choose between tuples and lists based upon your data. In
|> situations where you have a small, fixed collection of objects of possibly
|> differing types, use a tuple. In situations where have a collection of
|> objects of uniform type which might grow or shrink, use a list. For
|> example, an address might best be represented as a tuple:
|>
|> itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201")
|> caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866")
|>
|> Though all elements are actually strings, they are conceptually different
|> types. It probably makes no sense to define itcs as

| "Type" is not normally an ambiguous word. It seems to me that an
| explanation would stress, upfront, that in fact
| homogenous.hetereogenous in this context is at an abstract level, and
| unrelated to type,as such and as your example illustrates.
|
| Or else, why does the word "type" need to occur at all, other than
| perhaps to explain, explicitily, it is not of relevance

Apologies in advance if someone has already said this. It may
be a little too algebraic for the Python world, but for me the
difference can be expressed like this -

n > 0 or m < sizeof(a) and
conceptual_type(a) == conceptual_type(a[n:m])

If that holds, then the conceptual type is naturally implemented
with a list.

I'm not sure it's right to say that the elements of a tuple are
necessarily of conceptually different types, distinguished only
by their positiion. But the point is that they _are_ distinguished
by position (so a slice is not substitable with its source.)

Of course this still relies on a notion of conceptual type that
can't be expressed literally in Python, but it's a healthy one.

Donn Cave, (e-mail address removed)