Lists and Tuples

[Roy Smith]

Re: Lists and Tuples

In article <r650tv4f9b2k96 7jgc0cta3vllfoh b49il@4ax.com>,
Jeff Wagner <JWagner@hotmai l.com> wrote:
[color=blue]
> 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[/color]

The big difference is that tuples (because they are immutable) can be
used as dictionary keys.

So, if you are going to use it as a key, it's got to be a tuple. If
you're going to want to add/delete/change items in it, it's got to be a
list.

If you will never change it, but have no syntatic constraint forcing it
to be immutable, you can pick whichever turns you on. From a stylistic
point of view, I tend to think of tuples when I need to bundle up a
collection of related items (such as a function returning multiple
items). Lists make me think of number of the same kind of item.

[Roy Smith]

Re: Lists and Tuples

Joe Francia <usenet@soraia. com> wrote:[color=blue]
> For example, a Cartesian coordinate is appropriately represented as a
> tuple of two or three numbers.[/color]

I would agree if you're explicitly talking about 2-space or 3-space.
But if you're dealing with higher-order geometries, then a coordinate
becomes an N-vector and now it starts to feel more like a list than a
tuple.

I can't put any rigorous argument behind that, it's just what (to me)
feels right.

[Roy Smith]

Re: Lists and Tuples

I just stumbled upon an interesting tuple/list dichotomy.

The new isinstance() function can take a tuple (but not a list) as its
second argument. Why? Logically, it should take any sequence. The
operation it's doing is essentially:

for aType in sequence:
if isinstance (thing, aType):
return True
return False

I don't see any reason it should reject a list, but it does:
[color=blue][color=green][color=darkred]
>>> isinstance (1, [str, int])[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types

This is documented, but it still seems strange. Why go out of your way
to reject a list when a list is really a perfectly reasonable thing to
pass in that context?

Same deal with issubclass().

[Mel Wilson]

Re: Lists and Tuples

In article <bqpfde$426$0@2 16.39.172.122>, bokr@oz.net (Bengt Richter) wrote:[color=blue]
>On Thu, 04 Dec 2003 21:45:23 -0800, David Eppstein <eppstein@ics.u ci.edu> wrote:[color=green]
>>That's true, but another answer is: you should use tuples for short
>>sequences of diverse items (like the arguments to a function). You
>>should use lists for longer sequences of similar items.
>>[/color]
>I'm curious what you're getting at. I.e., what does diversity or
>similarity have to do with the choice? Is that an aesthetic thing?
>(In which case 'should' should be qualified a bit, IWT ;-)
>Or what am I missing?[/color]

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.

Python 3.3 (#22, Jul 29 2013, 14:34:42) [MSC v.9200 96 bit (Intel)] on win96
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> t = (1,4,7,34,789)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
HomogeneityErro r: tuple elements are not diverse[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]


Regards. Mel.

[David Eppstein]

Re: Lists and Tuples

In article <roy-9E698D.11180005 122003@reader2. panix.com>,
Roy Smith <roy@panix.co m> wrote:
[color=blue]
> The new isinstance() function can take a tuple (but not a list) as its
> second argument. Why? Logically, it should take any sequence.[/color]

What should it do if the second argument is a type object that is also
iterable?

E.g. suppose that iter(bool) produced the sequence True, False. ...

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Ron Adam]

Re: Lists and Tuples

On Fri, 5 Dec 2003 16:59:57 +1100, Andrew Bennetts
<andrew-pythonlist@puzz ling.org> wrote:
[color=blue]
>On Fri, Dec 05, 2003 at 05:19:33AM +0000, Jeff Wagner wrote:[color=green]
>> 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?[/color]
>
>What's the difference?
>[/color]


Items in lists and not in tuples:

[color=blue][color=green][color=darkred]
>>>> import sets
>>>> sets.Set(dir(li st)).difference (sets.Set(dir(t uple)))[/color][/color]
>Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert',
>'__setslice__' , 'count', 'remove', '__setitem__', '__iadd__', 'pop',
>'__delitem__ ', 'append', '__imul__'])
>
>;)
>
>-Andrew.
>[/color]


And Items in tuples and not in lists:
[color=blue][color=green][color=darkred]
>>> sets.Set(dir(tu ple)).differenc e(sets.Set(dir( list)))[/color][/color][/color]
Set(['__getnewargs__ '])



Items in both tuples and lists:
[color=blue][color=green][color=darkred]
>>> sets.Set(dir(tu ple)).intersect ion(sets.Set(di r(list)))[/color][/color][/color]
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]

Re: Lists and Tuples



Jeff Wagner wrote:
[color=blue]
> On 04 Dec 2003 21:31:12 -0800, Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrotf:
>
>[color=green]
>>Jeff Wagner <JWagner@hotmai l.com> writes:
>>[color=darkred]
>>>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?[/color]
>>
>>
>>
>>Try this with a list:
>>
>> a = [1, 2, 3, 4, 5]
>> a[3] = 27
>> print a
>>
>>Then try it with a tuple.[/color]
>
>
> 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.[/color]

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

Colin W.[color=blue]
>
> Jeff[/color]

[Fredrik Lundh]

Re: Lists and Tuples

Ron Adam wrote:
[color=blue]
> Maybe someone could tell me how and/or when __getnewargs__ is used?[/color]

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

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

</F>

[Fredrik Lundh]

Re: Lists and Tuples

Douglas Alan wrote:
[color=blue][color=green][color=darkred]
> >> Fredrik Lundh actually called me names a couple years back for
> >> asserting this, but Python luminary (and rude fellow) or not, he is
> >> dead wrong.[/color][/color]
>[color=green]
> > I'm never dead wrong.[/color]
>
> 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.[/color]

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]

Re: Lists and Tuples

On Fri, 5 Dec 2003 11:10:34 -0600, Skip Montanaro <skip@pobox.com >
wrote:

[color=blue]
>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[/color]

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" , "heterogeno us" 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.hete reogenous 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]

Re: Lists and Tuples

Arthur wrote:
[color=blue]
> "Type" is not normally an ambiguous word.[/color]

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

</F>

[Arthur]

Re: Lists and Tuples

On Sun, 7 Dec 2003 15:09:48 +0100, "Fredrik Lundh"
<fredrik@python ware.com> wrote:
[color=blue]
>Arthur wrote:
>[color=green]
>> "Type" is not normally an ambiguous word.[/color]
>
>really? in my experience, "type" and "object" are about as ambiguous
>as words can get, especially when you're talking about Python.
>
></F>[/color]

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

Art

[Arthur]

Re: Lists and Tuples

On Sun, 07 Dec 2003 15:07:58 GMT, Arthur <ajsiegel@opton line.com>
wrote:
[color=blue]
>On Sun, 7 Dec 2003 15:09:48 +0100, "Fredrik Lundh"
><fredrik@pytho nware.com> wrote:
>[color=green]
>>Arthur wrote:
>>[color=darkred]
>>> "Type" is not normally an ambiguous word.[/color]
>>
>>really? in my experience, "type" and "object" are about as ambiguous
>>as words can get, especially when you're talking about Python.
>>
>></F>[/color]
>
>I am sure you are right. On faith. Though its not particularly
>helpful.
>
>Art[/color]

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]

Re: Lists and Tuples

"Fredrik Lundh" <fredrik@python ware.com> writes:
[color=blue]
> 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.[/color]

Your characterizatio n 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.
[color=blue]
> two years later, you haven't learned a thing; that's pretty tragic.[/color]

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]

Humpty Dumpty (was Re: Lists and Tuples)

In article <mailman.190.10 70806215.16879. python-list@python.org >,
Fredrik Lundh <fredrik@python ware.com> wrote:[color=blue]
>Arthur wrote:[color=green]
>>
>> "Type" is not normally an ambiguous word.[/color]
>
>really? in my experience, "type" and "object" are about as ambiguous
>as words can get, especially when you're talking about Python.[/color]

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.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.