lists v. tuples

[MartinRinehart@gmail.com]

What are the considerations in choosing between:

return [a, b, c]

and

return (a, b, c) # or return a, b, c

Why is the immutable form the default?

[castironpi@gmail.com]

Re: lists v. tuples

On Mar 17, 6:49 am, MartinRineh...@ gmail.com wrote:

What are the considerations in choosing between:
>
   return [a, b, c]
>
and
>
    return (a, b, c) # or return a, b, c
>
Why is the immutable form the default?

Using a house definition from some weeks ago, a tuple is a data
structure such which cannot contain a refrence to itself. Can a
single expression refer to itself ever?

[Ninereeds]

Re: lists v. tuples

On Mar 17, 12:28 pm, castiro...@gmai l.com wrote:

Why is the immutable form the default?

>
Using a house definition from some weeks ago, a tuple is a data
structure such which cannot contain a refrence to itself. Can a
single expression refer to itself ever?

Can't imagine why that feature was highlighted in particular, but a
list can reference itself even though an expression can't.

The following example looks a bit self-referential, but isn't...

a = 2
a = [1, a, 3] # result [1, 2, 3]

The following additional line, however does create a self-referencing
list...

a [1] = a

The result being [1, [...], 2]

It's nice to see that Python can handle the output for this without
going into an infinite recursion - which is exactly what it used to do
in the distant past.

A tuple cannot be made to reference itself because it cannot be
modified after creation. The key point is that lists are mutable,
whereas tuples are not.

[Steven D'Aprano]

Re: lists v. tuples

On Mon, 17 Mar 2008 05:28:19 -0700, castironpi wrote:

a tuple is a data
structure such which cannot contain a refrence to itself.

>>a = [] # a list
>>b = (a, None) # a tuple
>>a.append(b)
>>print b

([([...], None)], None)

>>b[0][0] is b

True


So, yes tuples can contain a reference to themselves, but only indirectly.

Can a single expression refer to itself ever?

You can't refer to an object until it exists, so no.




--
Steven

[Duncan Booth]

Re: lists v. tuples

MartinRinehart@ gmail.com wrote:

What are the considerations in choosing between:
>
return [a, b, c]
>
and
>
return (a, b, c) # or return a, b, c
>

A common explanation for this is that lists are for homogenous
collections, tuples are for when you have heterogenous collections i.e.
related but different things.

If you follow this line of argument then when you want to return some
values from a function, e.g. url, headers and data a tuple would be the
appropriate thing to use.

If you really are returning a homogenous collection (e.g. top 5 urls)
then a list would be more appropriate.

Another way to look at it is what you expect the caller to do with the
results. If they are just going to unpack a fixed set of values then a
tuple makes sense. If you write:

return url, headers, data

then the caller writing:

url, headers, data = frobozz()

has a certain symmetry.

It isn't set in stone of course: use whatever you want or whatever feels
right at the time.

Why is the immutable form the default?
>

It isn't. It uses whichever type you specify but tuples may involve a
little less typing.

[Duncan Booth]

Re: lists v. tuples

Ninereeds <stephenhorne10 0@aol.comwrote:

On Mar 17, 1:31 pm, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:
>

>A common explanation for this is that lists are for homogenous
>collections, tuples are for when you have heterogenous collections i.e.
>related but different things.

>
I interpret this as meaning that in a data table, I should have a list
of records but each record should be a tuple of fields, since the
fields for a table usually have different forms whereas the records
usually all have the same record layout.

That is indeed what Python's Database API usually does (although it doesn't
mandate it):

.fetchmany([size=cursor.arr aysize])

Fetch the next set of rows of a query result, returning a
sequence of sequences (e.g. a list of tuples). An empty
sequence is returned when no more rows are available.

[castironpi@gmail.com]

Re: lists v. tuples

On Mar 17, 1:31 pm, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

>

>A common explanation for this is that lists are for homogenous
>collections, tuples are for when you have heterogenous collections i.e.
>related but different things.

>

I interpret this as meaning that in a data table, I should have a list
of records but each record should be a tuple of fields, since the
fields for a table usually have different forms whereas the records
usually all have the same record layout.

>

>b in b

False

That's actually interesting.

>>a= []
>>a.append( a )
>>a

[[...]]

>>a in a

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded in cmp

[Duncan Booth]

Re: lists v. tuples

castironpi@gmai l.com wrote:

On Mar 17, 1:31 pm, Duncan Booth <duncan.bo...@i nvalid.invalid>
wrote:

>>

>A common explanation for this is that lists are for homogenous
>collections, tuples are for when you have heterogenous
>collections i.e. related but different things.

>>

I interpret this as meaning that in a data table, I should have a
list of records but each record should be a tuple of fields,
since the fields for a table usually have different forms whereas
the records usually all have the same record layout.

>>

>>b in b

>False

>
That's actually interesting.

Just for the avoidance of doubt, I didn't write the 'b in b' line:
castironpi is replying to himself without attribution.

P.S. I still don't see the relevance of any of castironpi's followup to my
post, but since none it made any sense to me I guess it doesn't matter.

[George Sakkis]

Re: lists v. tuples

On Mar 18, 5:34 pm, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

castiro...@gmai l.com wrote:

On Mar 17, 1:31 pm, Duncan Booth <duncan.bo...@i nvalid.invalid>
wrote:

>

>A common explanation for this is that lists are for homogenous
>collections, tuples are for when you have heterogenous
>collections i.e. related but different things.

>

I interpret this as meaning that in a data table, I should have a
list of records but each record should be a tuple of fields,
since the fields for a table usually have different forms whereas
the records usually all have the same record layout.

>

>b in b
False

>

That's actually interesting.

>
Just for the avoidance of doubt, I didn't write the 'b in b' line:
castironpi is replying to himself without attribution.
>
P.S. I still don't see the relevance of any of castironpi's followup to my
post, but since none it made any sense to me I guess it doesn't matter.

Plus, it does work fine over here:

Python 2.5.1 (r251:54863, May 8 2007, 14:46:30)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

>>a = []
>>a.append(a)
>>a

[[...]]

>>a in a

True


George