List vs tuples
 

A neewbie's question here, probably discussed before:
what's the purpose of having both lists AND tuples?
At the first (and second and third, to be honest) glance lists are just
tuples with extended functionality, so why have tuples around?
I've been working with Python for a few months now but haven't yet come
across a problem that would really require tuples.

Thanks in advance,
Mitja

Re: List vs tuples
 

* Mitja <tezt@email.si> [08-04-2004 17:42]:
> A neewbie's question here, probably discussed before:
> what's the purpose of having both lists AND tuples?

It's a FAQ, Indeed :)

http://www.python.org/doc/faq/genera...ist-data-types

Cheers,
Aloysio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAdbp33Z98a+m7958RAr1cAJsEJhzVCt13TH+nCFvU8q 4gR9WH4gCcCBB4
JpFvUm8/oLIsIo/Q6WRE2d4=
=LcVm
-----END PGP SIGNATURE-----

Re: List vs tuples
 

In article <c54cjb$5fs$1@planja.arnes.si>, "Mitja" <tezt@email.si>
wrote:

> A neewbie's question here, probably discussed before:
> what's the purpose of having both lists AND tuples?
> At the first (and second and third, to be honest) glance lists are just
> tuples with extended functionality, so why have tuples around?
> I've been working with Python for a few months now but haven't yet come
> across a problem that would really require tuples.
>
> Thanks in advance,
> Mitja

The biggest reason that I can think of is that tuples are immutable, and
you need an immutable object to be a dictionary key.

Also, without knowing the details of how they are implemented, my guess
would be that tuples are more efficient, as a direct result of their
immutability.

Re: List vs tuples
 

"Mitja" <tezt@email.si> wrote in message
news:c54cjb$5fs$1@planja.arnes.si...
> A neewbie's question here, probably discussed before:
> what's the purpose of having both lists AND tuples?
> At the first (and second and third, to be honest) glance lists are just
> tuples with extended functionality, so why have tuples around?
> I've been working with Python for a few months now but haven't yet come
> across a problem that would really require tuples.

It's a common question. A list is a data structure that is
intended to be used with homogenous members; that is,
with members of the same type.

You've probably used tuples without realizing it. For
example, the following idiom involves a tuple:

hours, minute, second = getTime()

where

def getTime(.....)
#some calc
return hour, minute, second

While it looks like return is returning multiple
objects, it actually isn't. It's returning one object:
a tuple of three elements which is then being
unpacked on the receiving end.

You could call the same routine this way as well:

result = getTime()

and result would be a tuple of three elements.

Another way of thinking about it is that you would
use a tuple the same way you would use a struct in
a language like C, if you didn't want to go to the trouble
of creating a full-fledged object for it.

John Roth

>
> Thanks in advance,
> Mitja
>
>

Re: List vs tuples
 

Mitja wrote on Thu, 8 Apr 2004 18:47:07 +0200:

> A neewbie's question here, probably discussed before:
> what's the purpose of having both lists AND tuples?
> At the first (and second and third, to be honest) glance lists are just
> tuples with extended functionality, so why have tuples around?

You can use tuples as keys in a dictionary, but you can't use lists for
that purpose (because they're mutable).

> I've been working with Python for a few months now but haven't yet come
> across a problem that would really require tuples.

That's possible. Lists offer many more facilities than tuples (mainly due
to them being mutable), so it's easier to just use a list (even if a tuple
could do the job).

--
Yours,

Andrei

=====
Real contact info (decode with rot13):
cebwrpg5@jnanqbb.ay. Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V ernq
gur yvfg, fb gurer'f ab arrq gb PP.

Re: List vs tuples
 

"John Roth" <newsgroups@jhrothjr.com> wrote:
> A list is a data structure that is intended to be used with
> homogenous members; that is, with members of the same type.

There's really nothing about a list which makes it more suitable for
homogeneous elements than a tuple. It's true that people do tend to
think tuple when they want a mixed collection of objects, but there's
nothing in the language semantics which makes that so.

I've written lots of code which parses data files. If you've got a
sequence of arbitrary type objects, the easiest way to process them is
often to read them sequentially and append them to a list. I don't see
anything wrong with that. For example, I once had to write some code
which parsed SQL statements that looked something like:

insert into foo values (1, 2, 'foo', 3.14, 'bar', 4, 5, 'baz', ...);

There were a total of about 30 items of mixed type (strings, integers,
and floats) in the ()'s.

One of the really nice things about Python (vs. C++ or Java) is that
you're not bound by the tyranny of static typing. This is a perfect
example of how this makes life so simple.

Re: List vs tuples
 

"Roy Smith" <roy@panix.com> wrote in message
news:roy-BDDD71.17205008042004@reader1.panix.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote:
> > A list is a data structure that is intended to be used with
> > homogenous members; that is, with members of the same type.
>
> There's really nothing about a list which makes it more suitable for
> homogeneous elements than a tuple. It's true that people do tend to
> think tuple when they want a mixed collection of objects, but there's
> nothing in the language semantics which makes that so.
>
> I've written lots of code which parses data files. If you've got a
> sequence of arbitrary type objects, the easiest way to process them is
> often to read them sequentially and append them to a list. I don't see
> anything wrong with that. For example, I once had to write some code
> which parsed SQL statements that looked something like:
>
> insert into foo values (1, 2, 'foo', 3.14, 'bar', 4, 5, 'baz', ...);
>
> There were a total of about 30 items of mixed type (strings, integers,
> and floats) in the ()'s.
>
> One of the really nice things about Python (vs. C++ or Java) is that
> you're not bound by the tyranny of static typing. This is a perfect
> example of how this makes life so simple.

This is perfectly true, but that's the intention. Guido says
so himself. Lots of people either don't believe him, or
don't understand him.

If you think of it this way, the "quirks" become understandable:
it makes no sense to append something to the end of a c type
struct, for example.

John Roth

Re: List vs tuples
 

In article <roy-BDDD71.17205008042004@reader1.panix.com>,
Roy Smith <roy@panix.com> wrote:
> "John Roth" <newsgroups@jhrothjr.com> wrote:
>> A list is a data structure that is intended to be used with
>> homogenous members; that is, with members of the same type.
>
> There's really nothing about a list which makes it more suitable for
> homogeneous elements than a tuple. It's true that people do tend to
> think tuple when they want a mixed collection of objects, but there's
> nothing in the language semantics which makes that so.
>
> I've written lots of code which parses data files. If you've got a
> sequence of arbitrary type objects, the easiest way to process them is
> often to read them sequentially and append them to a list. I don't see
> anything wrong with that. For example, I once had to write some code
> which parsed SQL statements that looked something like:
>
> insert into foo values (1, 2, 'foo', 3.14, 'bar', 4, 5, 'baz', ...);
>
> There were a total of about 30 items of mixed type (strings, integers,
> and floats) in the ()'s.
>
> One of the really nice things about Python (vs. C++ or Java) is that
> you're not bound by the tyranny of static typing. This is a perfect
> example of how this makes life so simple.

Oh no, here we go again.

In the hope that we can all get along, here's how
both of these arguments can be true. And I'm sure
Guido would agree if he were reading this, unless
he was in an unusually obtuse frame of mind.

Lists are indeed homogeneous by nature, but that
doesn't mean that each element has the same type
as the next. It means that any slice of the list
has the same "type" as any other slice.

When we are dealing with a record type, an ordered
collection of items where an item's meaning is
determined by its position, this obviously should
be a tuple. For example, the tm struct returned
from time.localtime(): each member is an integer,
but it's not homogeneous in the list sense - the
only valid slice of a tm value is [:], any other
slice is not a tm value, its type is different
even if it is still a tuple.

When we are dealing with a regular list, its type
is the same before and after you append() a new
element. That doesn't mean that the new element
is the same type as its predecessor, it just means
that the list isn't itself a new type now that it
has that last element.

Donn Cave, donn@u.washington.edu

Re: List vs tuples
 

On Thu, 8 Apr 2004 16:57:25 -0400, "John Roth"
<newsgroups@jhrothjr.com> wrote:

>It's a common question. A list is a data structure that is
>intended to be used with homogenous members; that is,
>with members of the same type.

As succeint and comforting as the explanation is....

I have consulted the Python Desgin Manual: Occult Edition, and if my
search of the list archives is true, the statement:

"""

A list is a data structure that is intended to be used with homogenous
members; that is,with members of the same type.

"""

is still 6 incantaions shy of becoming meaningful.

5 now actually.

Art

Re: List vs tuples
 

>>>>> "John" == John Roth <newsgroups@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.

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.

John> You've probably used tuples without realizing it. For example, the
John> following idiom involves a tuple:

John> hours, minute, second = getTime()

John> where

John> def getTime(.....) #some calc return hour, minute, second

John> While it looks like return is returning multiple objects, it
John> actually isn't. It's returning one object: a tuple of three
John> elements which is then being unpacked on the receiving end.

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

John> You could call the same routine this way as well:

John> result = getTime()

John> and result would be a tuple of three elements.

And if getTime() give you a list of course result would be a list instead.
Nothing magic.

John> Another way of thinking about it is that you would use a tuple the
John> same way you would use a struct in a language like C, if you
John> didn't want to go to the trouble of creating a full-fledged object
John> for it.

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.

Regards,
Isaac.