tuple.index()

[Nick Maclaren]

Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it. Yes,
I know it's a fairly rare requirement.
Regards,
Nick Maclaren.

[Fredrik Lundh]

Nick Maclaren wrote:

Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it.

hah! not being able to remove or add things to tuples is an even
bizarrer restriction!

</F>

[Nick Maclaren]

In article <ma***************************************@python. org>,
Fredrik Lundh <fr*****@pythonware.comwrites:
|>
| Why doesn't the tuple type have an index method? It seems such a
| bizarre restriction that there must be some reason for it.
|>
|hah! not being able to remove or add things to tuples is an even
|bizarrer restriction!

Eh? Why?

My understanding of the difference between a tuple and a list is
PRECISELY that the former is immutable and the latter mutable.
But an index method makes precisely as much sense on an immutable
sequence as it does on a mutable one.
Regards,
Nick Maclaren.

[Glenn Hutchings]

Nick Maclaren wrote:

Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it.

In fact, tuples have no non-__underscored__ methods at all. The list
count() method would also be useful for tuples, since it doesn't modify
anything. I have no idea why they aren't implemented either.

Glenn

[Fredrik Lundh]

Nick Maclaren wrote:

My understanding of the difference between a tuple and a list is
PRECISELY that the former is immutable and the latter mutable.

while tuples can be used as "frozen lists", that's definitely not what
they are, from a design perspective.

just like in math [1], a Python tuple is a heterogeneous sequence where
the position implies type and usage. in contrast, a list is a homo-
geneous collection where all the items are "the same" in some sense,
no matter where they are. if you sort or otherwise reorder a list
of things, it's still a list of the same things. if you sort a tuple,
you'll break it.

in other words, you're supposed to know what the individual items are in
a tuple; if you feel the need to search for things by value in a tuple,
you're using the wrong container type.

</F>

1) http://en.wikipedia.org/wiki/Tuple

[Simon Brunning]

On 14 Dec 2006 11:24:04 GMT, Nick Maclaren <nm**@cus.cam.ac.ukwrote:

>
Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it. Yes,
I know it's a fairly rare requirement.

It's because, philosophically, a Python tuple isn't just a read-only list.

Lists are for homogeneous data, all entries being of the same 'type'.
('Type' here doesn't refer to class or anything like that - just
conceptual type - what kind of thin g it is.) So, you can infer no
semantic meaning from an items position in the list. Sorting makes
sence,m and does looking though a list to find something - hence
index().

A tuple, on the other hand, is heterogeneous. The fact that an item is
the nth item is a tuple *means* something. Sorting a tuple would make
no sense, even if it were possible, and you are supposed to know where
in the tuple things are, so it makes no sense to search for it.

--
Cheers,
Simon B
si***@brunningonline.net
http://www.brunningonline.net/simon/blog/

[Glenn Hutchings]

Simon Brunning wrote:

It's because, philosophically, a Python tuple isn't just a read-only list.

But there are situations where you might want to treat it as a
read-only list. E.g., an argument to a function, so that you can
guarantee the function won't modify it. In that case, it makes sense
for the non-modifying methods (index() and count()) to be available.

[Roberto Bonvallet]

Glenn Hutchings wrote:

But there are situations where you might want to treat it as a
read-only list. E.g., an argument to a function, so that you can
guarantee the function won't modify it. In that case, it makes sense
for the non-modifying methods (index() and count()) to be available.

list(my_arg).index(...)

--
Roberto Bonvallet

[Fredrik Lundh]

Glenn Hutchings wrote:

But there are situations where you might want to treat it as a
read-only list. E.g., an argument to a function, so that you can
guarantee the function won't modify it.

if you cannot trust your own code not to modify objects you pass to it,
I'm not sure Python's the right language for you.

</F>

[Glenn Hutchings]

Roberto Bonvallet wrote:

list(my_arg).index(...)

Absolutely -- you can work around the limitation without any problems.
But the question is, why doesn't the list type share all its
non-modifying methods with the tuple type? All the previous arguments
about "homogenous" and "heterogenous" in this thread sound bogus to me.
Python is first and foremost a practical language; what lists and
tuples are supposedly "for" strikes me as being irrelevant.

Glenn

[Glenn Hutchings]

Fredrik Lundh wrote:

if you cannot trust your own code not to modify objects you pass to it,
I'm not sure Python's the right language for you.

It's not my own code I'm worried about. :-)

[Simon Brunning]

On 14 Dec 2006 06:03:07 -0800, Glenn Hutchings <zo*****@googlemail.comwrote:

All the previous arguments
about "homogenous" and "heterogenous" in this thread sound bogus to me.
Python is first and foremost a practical language; what lists and
tuples are supposedly "for" strikes me as being irrelevant.

Tell that to Guido. They are his arguments.

--
Cheers,
Simon B
si***@brunningonline.net
http://www.brunningonline.net/simon/blog/

[Simon Brunning]

On 12/14/06, Simon Brunning <si***@brunningonline.netwrote:

Tell that to Guido. They are his arguments.

On 2nd thoughts, don't. He has enough on his plate at the moment. ;-)

--
Cheers,
Simon B
si***@brunningonline.net
http://www.brunningonline.net/simon/blog/

[Fredrik Lundh]

Glenn Hutchings wrote:

Python is first and foremost a practical language; what lists and
tuples are supposedly "for" strikes me as being irrelevant.

if you don't want to understand the design, nobody can force you. but arguing
that the people behind the design "don't get it" isn't very practical.

and if you want random hacks and no design philosophy, use PHP.

</F>

[Simon Brunning]

On 14 Dec 2006 06:05:12 -0800, Glenn Hutchings <zo*****@googlemail.comwrote:

It's not my own code I'm worried about. :-)

If you want a language that protects you not only from your own
mistakes, but also the mistakes of others, well, err, sorry, I'm not
sure I can help you. Eiffel, perhaps?

<http://en.wikipedia.org/wiki/Design_by_contract>

--
Cheers,
Simon B
si***@brunningonline.net
http://www.brunningonline.net/simon/blog/

[Glenn Hutchings]

Fredrik Lundh wrote:

if you don't want to understand the design, nobody can force you. but arguing
that the people behind the design "don't get it" isn't very practical.

I'm not arguing that at all. What I'm saying is that from the
perspective of someone not interested in design issues, it seems like
an omission for tuples to be missing the non-modifying methods that
lists have.

Glenn

[Nick Maclaren]

In article <11**********************@n67g2000cwd.googlegroups .com>,
"Glenn Hutchings" <zo*****@googlemail.comwrites:
|Fredrik Lundh wrote:
|>
| if you don't want to understand the design, nobody can force you. but arguing
| that the people behind the design "don't get it" isn't very practical.
|>
|I'm not arguing that at all. What I'm saying is that from the
|perspective of someone not interested in design issues, it seems like
|an omission for tuples to be missing the non-modifying methods that
|lists have.

And, from the perspective of someone VERY interested in design issues,
from the viewpoint of program validation (a.k.a mathematical models,
a.k.a. 'program proving' a.k.a. 'software engineering') it also seems
like one!

If lists are intended to be homogeneous, then they should be checked
for that, and an exception raised when an attempt is to make them
non-homogeneous. At least as a Python checking option.

If tuples are intended to be bags, then it makes no sense to allow
them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
'i = a.index(x)' have dual properties - and are true duals if you
include the constraint of no duplicate elements.

I remain baffled. I accept the explanations, but what I am now
confused by is the reason for the explanations ....
Regards,
Nick Maclaren.

[Georg Brandl]

Nick Maclaren schrieb:

In article <11**********************@n67g2000cwd.googlegroups .com>,
"Glenn Hutchings" <zo*****@googlemail.comwrites:
|Fredrik Lundh wrote:
|>
| if you don't want to understand the design, nobody can force you. but arguing
| that the people behind the design "don't get it" isn't very practical.
|>
|I'm not arguing that at all. What I'm saying is that from the
|perspective of someone not interested in design issues, it seems like
|an omission for tuples to be missing the non-modifying methods that
|lists have.

And, from the perspective of someone VERY interested in design issues,
from the viewpoint of program validation (a.k.a mathematical models,
a.k.a. 'program proving' a.k.a. 'software engineering') it also seems
like one!

If lists are intended to be homogeneous, then they should be checked
for that, and an exception raised when an attempt is to make them
non-homogeneous. At least as a Python checking option.

There you have the "consenting adults" philosophy again: You know what lists
are for, so you can use them for it. You can also use them for something else,
but in that case it's moot to complain about missing features.

If tuples are intended to be bags, then it makes no sense to allow
them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
'i = a.index(x)' have dual properties - and are true duals if you
include the constraint of no duplicate elements.

You're describing sets. Tuples are not sets. Sets are not indexable and have
unique elements.

Indexing is the *vital* point of tuples. They are an ordered collection of
values, and you are supposed to know which data is found at which index.
Don't tell me that tuples in maths are sets.

For a mathematical example, take

A = { (x,y) : 0 < x < 1, 0 < y < 1 }

Here, (x,y) is a 2-tuple, and you know that at index 0 there's the x-coordinate
of a point contained in the square A, and at index 1 there's the y-coordinate.

Georg

[Fredrik Lundh]

Nick Maclaren wrote:

If lists are intended to be homogeneous, then they should be checked
for that, and an exception raised when an attempt is to make them
non-homogeneous.

so how would that check work, given that Python's type model is based on
duck typing

http://en.wikipedia.org/wiki/Duck_typing

?

</F>

[Nick Maclaren]

In article <el**********@news.albasani.net>,
Georg Brandl <g.*************@gmx.netwrites:
|
| If lists are intended to be homogeneous, then they should be checked
| for that, and an exception raised when an attempt is to make them
| non-homogeneous. At least as a Python checking option.
|>
|There you have the "consenting adults" philosophy again: You know what lists
|are for, so you can use them for it. You can also use them for something else,
|but in that case it's moot to complain about missing features.

One of the places where Cobol, Ada and Python are superior to C and Perl
is that they regard checking as a part of the language.

| If tuples are intended to be bags, then it makes no sense to allow
| them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
| 'i = a.index(x)' have dual properties - and are true duals if you
| include the constraint of no duplicate elements.
|>
|You're describing sets. Tuples are not sets. Sets are not indexable and have
|unique elements.

Actually, I was describing bags - like sets, but with element multiplicity.
See http://en.wikipedia.org/wiki/Multiset

|Indexing is the *vital* point of tuples. They are an ordered collection of
|values, and you are supposed to know which data is found at which index.

Memo to self: you really MUST remember NEVER to use reductio ad absurdum
on Usenet.

The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples. There is no technical or
mathematical reason why it shouldn't be.
Regards,
Nick Maclaren.

[Glenn Hutchings]

Nick Maclaren wrote:

I remain baffled. I accept the explanations, but what I am now
confused by is the reason for the explanations ....

Maybe this archive posting, straight from the horse's mouth, will clear
things up once and for all...

http://www.python.org/search/hyperma...1992/0285.html

Glenn

[Fredrik Lundh]

Nick Maclaren wrote:

The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples. There is no technical or
mathematical reason why it shouldn't be.

so where would you put such an "index" implementation so it would work on
ANY data structure that can be subscripted by an integer value ?

</F>

[Nick Maclaren]

In article <ma***************************************@python. org>,
"Fredrik Lundh" <fr*****@pythonware.comwrites:
|Nick Maclaren wrote:
|>
| If lists are intended to be homogeneous, then they should be checked
| for that, and an exception raised when an attempt is to make them
| non-homogeneous.
|>
|so how would that check work, given that Python's type model is based on
|duck typing
|>
| http://en.wikipedia.org/wiki/Duck_typing

See my response to Georg Brandl (specifically the memo. to myself).
Regards,
Nick Maclaren.

[Nick Maclaren]

In article <11**********************@t46g2000cwa.googlegroups .com>,
"Glenn Hutchings" <zo*****@googlemail.comwrites:
|>
| I remain baffled. I accept the explanations, but what I am now
| confused by is the reason for the explanations ....
|>
|Maybe this archive posting, straight from the horse's mouth, will clear
|things up once and for all...
|>
|http://www.python.org/search/hyperma...1992/0285.html

Wonderful! Thanks. Yes, that does. It makes perfect sense. I did
say that I thought it would be a rarely used feature :-)
Regards,
Nick Maclaren.

[Nick Maclaren]

In article <ma***************************************@python. org>,
"Fredrik Lundh" <fr*****@pythonware.comwrites:
|>
| The point is that an index method makes sense on ANY data structure that
| can be subscripted by an integer value but, for reasons that aren't at
| all clear, is not defined for Python tuples. There is no technical or
| mathematical reason why it shouldn't be.
|>
|so where would you put such an "index" implementation so it would work on
|ANY data structure that can be subscripted by an integer value ?

In the same place you put the subscription method, clearly. I really
don't see the problem. I can see that it has not been done because
Guido and others felt that it wasn't worth doing, but not that it is
hard to do.
Regards,
Nick Maclaren.

[Neil Cerutti]

On 2006-12-14, Nick Maclaren <nm**@cus.cam.ac.ukwrote:

>
In article <11**********************@t46g2000cwa.googlegroups .com>,
"Glenn Hutchings" <zo*****@googlemail.comwrites:
|>
| I remain baffled. I accept the explanations, but what I am now
| confused by is the reason for the explanations ....
|>
|Maybe this archive posting, straight from the horse's mouth, will clear
|things up once and for all...
|>
|http://www.python.org/search/hyperma...1992/0285.html

Wonderful! Thanks. Yes, that does. It makes perfect sense.
I did say that I thought it would be a rarely used feature :-)

Though the full rationale no longer applies to strings, which now
have plenty of methods.

--
Neil Cerutti
Weight Watchers will meet at 7 p.m. Please use large double door at the side
entrance. --Church Bulletin Blooper

[Carsten Haese]

On Thu, 2006-12-14 at 15:57 +0000, Nick Maclaren wrote:

In article <ma***************************************@python. org>,
"Fredrik Lundh" <fr*****@pythonware.comwrites:
|>
| The point is that an index method makes sense on ANY data structure that
| can be subscripted by an integer value but, for reasons that aren't at
| all clear, is not defined for Python tuples. There is no technical or
| mathematical reason why it shouldn't be.
|>
|so where would you put such an "index" implementation so it would work on
|ANY data structure that can be subscripted by an integer value ?

In the same place you put the subscription method, clearly.

Clearly not, because that would force *every* object that implements
__getitem__ to also implement index.

And to verify the truth of your assertion that index makes sense for
"ANY data structure that can be subscripted by an integer value",
consider the following theoretical but conceivable examples:

1) A mailbox object that returns the i-th message on subscripting.
2) A scroll cursor in a database that returns the i-th row of the result
set.
3) A prime number generator that calculates the i-th prime number.

Does .index() make sense for them? How would it be implemented?

-Carsten

[Fredrik Lundh]

Nick Maclaren wrote:

In the same place you put the subscription method, clearly.

which is?

</F>

[Fredrik Lundh]

Nick Maclaren wrote:

See my response to Georg Brandl (specifically the memo. to myself).

"reductio ad absurdum" and "arbitrary handwaving" are two different
things, though.

</F>

[Nick Maclaren]

In article <ma***************************************@python. org>,
Carsten Haese <ca*****@uniqsys.comwrites:
| |>
| |so where would you put such an "index" implementation so it would work on
| |ANY data structure that can be subscripted by an integer value ?
|
| In the same place you put the subscription method, clearly.
|>
|Clearly not, because that would force *every* object that implements
|__getitem__ to also implement index.

Well, yes, but why is that impossible? You may feel that it is
undesirable, but that is not the same at all. And there is no problem
with providing a generic default version of index that just does a
linear search, so only objects that wanted to optimise index would
need to provide anything.

|And to verify the truth of your assertion that index makes sense for
|"ANY data structure that can be subscripted by an integer value",
|consider the following theoretical but conceivable examples:
|>
|1) A mailbox object that returns the i-th message on subscripting.
|2) A scroll cursor in a database that returns the i-th row of the result
|set.
|3) A prime number generator that calculates the i-th prime number.
|>
|Does .index() make sense for them? How would it be implemented?

You are correct that it does also need some sort of a concept of
equivalence, but a language like Python always has one - the 'is'
operator, if nothing else.

index makes sense for all of the above examples, and the implementation
couls be based on 'is' for (1) and (2), and on value for (3). And, as
mentioned above, it could be implemented as a linear search, if nothing
else works.

Mathematically, the counterexamples are only lists of entities where
there is no definable concept of equivalence between entities, and
Python has no such entities as far as I know.

Guido's response is fine - we didn't because we didn't think that it
was worth doing. One can dissent, but it makes perfect sense.
Regards,
Nick Maclaren.

[Fredrik Lundh]

Nick Maclaren wrote:

Guido's response is fine - we didn't because we didn't think that it
was worth doing. One can dissent, but it makes perfect sense.

so which Guido should you trust more? the "tuples should not be used
for arrays of homogeneous data" and "searching tuples doesn't make
sense" guy seen e.g here:

http://mail.python.org/pipermail/pyt...ry/019664.html
http://mail.python.org/pipermail/pyt...ch/033964.html
http://mail.python.org/pipermail/pyt...ch/033972.html

or that "we didn't add list methods to tuples because we're lazy" guy?

</F>

[Fredrik Lundh]

Fredrik Lundh wrote:

so which Guido should you trust more?

not to mention the "If you have a need for using count() or index() on
tuples, you're using them the wrong way" guy:

http://mail.python.org/pipermail/pat...ry/004071.html

</F>

[Carl Banks]

Glenn Hutchings wrote:

Simon Brunning wrote:

It's because, philosophically, a Python tuple isn't just a read-only list.

But there are situations where you might want to treat it as a
read-only list. E.g., an argument to a function, so that you can
guarantee the function won't modify it.

Seems to me a misplaced fear. Do you take steps to also protect other
mutable arguments (dicts, class instances, etc.)? If not, there should
be no reason why you should protect lists that way either. If so, you
could do a similar thing for lists as well.

For the record, I don't agree with tuple's absent count and index
methods either, but for other reasons. It's a minor thing. I deal
with it.

In that case, it makes sense
for the non-modifying methods (index() and count()) to be available.

As I said in another thread, making sense is about step one out of a
hundred for getting your change into the language.
Carl Banks

[Nick Maclaren]

In article <11*********************@l12g2000cwl.googlegroups. com>,
"Carl Banks" <pa************@gmail.comwrites:
|Glenn Hutchings wrote:
| Simon Brunning wrote:
| It's because, philosophically, a Python tuple isn't just a read-only list.
|
| But there are situations where you might want to treat it as a
| read-only list. E.g., an argument to a function, so that you can
| guarantee the function won't modify it.
|>
|Seems to me a misplaced fear. Do you take steps to also protect other
|mutable arguments (dicts, class instances, etc.)? If not, there should
|be no reason why you should protect lists that way either. If so, you
|could do a similar thing for lists as well.

Well, in an ideal language, yes. And, yes, that is the correct solution.
If I were a designing a language, mutability would be an orthogonal
property to type. It isn't a misplaced fear, but the extra protection
provided by doing that only for tuples is like locking one door out of
ten to deter burglars - good practice, if there is no downside, but not
worth putting much effort into.

And the 'misplaced fear' assertion is equally applicable to the misuse
of tuples - but that viewpoint is clearly heretical :-)

|For the record, I don't agree with tuple's absent count and index
|methods either, but for other reasons. It's a minor thing. I deal
|with it.

Indeed. The code to sort out the problem was trivial. I was curious
as to the reason, since there was no technical or mathematical one, and
seem to have accidentally committed one of Python's Seven Unforgiveable
Heresies, to have lost my soul irredeemably, and to be in danger of
being burnt at the stake.

Ah, well.

[ Incidentally, my use was in argument decoding, where the Python layer
holds the arguments as strings, and I need to pass them as an index to C
(so they DO form a respectable tuple even in Guido's sense, being fixed
in number and value and just happening to be homogeneous). ]

Regards,
Nick Maclaren.

[Fredrik Lundh]

Nick Maclaren wrote:

Indeed. The code to sort out the problem was trivial. I was curious
as to the reason, since there was no technical or mathematical one

you still haven't explained what your solution to the technical
issues is, though. if simply repeating that something is trivial
would make the real issues go away, the Py3K developers would
have made a lot more progress over the last year.

seem to have accidentally committed one of Python's Seven
Unforgiveable Heresies

duck-typing applies to usenet posters too, you know. if you look like a ...

</F>

[Carl Banks]

Nick Maclaren wrote:

It isn't a misplaced fear, but the extra protection
provided by doing that only for tuples is like locking one door out of
ten to deter burglars - good practice, if there is no downside, but not
worth putting much effort into.

Maybe "inconsistent" fear is a better word. It's like when people are
deathly afraid to get on an airplane, but think nothing of riding in a
car without a seatbelt.
Carl Banks

[Nick Maclaren]

In article <11*********************@16g2000cwy.googlegroups.c om>,
"Carl Banks" <pa************@gmail.comwrites:
|>
| It isn't a misplaced fear, but the extra protection
| provided by doing that only for tuples is like locking one door out of
| ten to deter burglars - good practice, if there is no downside, but not
| worth putting much effort into.
|>
|Maybe "inconsistent" fear is a better word. It's like when people are
|deathly afraid to get on an airplane, but think nothing of riding in a
|car without a seatbelt.

I agree with that. I consider the difficulty of adding a reliable
immutable attribute in most languages to be a serious piece of
misdesign, but there isn't a huge amount of point unless it is done
properly. Unreliable safety devices are as likely to increase
errors as reduce them, at least in the hands of the naive.
Regards,
Nick Maclaren.

[Christoph Zwerschke]

Maybe there would be less dispute if this dogma/convention(?) "Tuples
are for heterogeneous data, list are for homogeneous data" would be
written down somewhere in the tutorial, reference or in PEP8, so people
would be aware of it.

And can somebody explain what is exactly meant with "homogenous data"?
That the type of the elements is the same in some technical or
philosophical meaning? Concretely speaking, which data type should I use
for coordinate tuples? Usually, tuples are used. Does this mean that I
should better use lists from now on because all the components have the
same type?

-- Christoph

[Tim Golden]

[Christoph Zwerschke]

And can somebody explain what is exactly meant with
"homogenous data"?

This seems to have been explained a few times
recently :) Basically, if you have a "list of xs"
and remove one item from it, it is still a "list of xs",
where "xs" might be people, coordinate-pairs, numbers
or whatever made sense to you. If you have a tuple
containing, say, a 2d coordinate pair, and remove something
from it, it's no longer a coordinate pair. If you add one to it,
it's something else as well (perhaps a 3d coord?)

A typical example of their combined use is a set of
rows returned from a database: each row is a tuple
of fields, the same as all other such rows, and removing
or adding a field would make no sense. However, add
a new row to the list and it remains a list of rows.

Now you can take this or leave it within Python. You
can but mixed values into a list so it isn't really a list
of "xs" unless "x" is just "thing". Likewise you can use
a tuple to hold a list of identical things although you
can't add to it or take away.

Concretely speaking, which data type should I use
for coordinate tuples? Usually, tuples are used. Does this mean that I
should better use lists from now on because all the components have the
same type?

This would seem to be slightly false logic (and very
possibly used tongue-in-cheek). Heterogeneous data
doesn't mean that each item *has* to be different, merely
that they *may* be.

TJG

[Simon Brunning]

On 14 Dec 2006 06:24:38 -0800, Glenn Hutchings <zo*****@googlemail.comwrote:

What I'm saying is that from the
perspective of someone not interested in design issues, it seems like
an omission for tuples to be missing the non-modifying methods that
lists have.

>From the perpective of somone not interested in Football, the offside

rule looks very strange - but I'm not making any suggestions as to how
it should be changed.

--
Cheers,
Simon B
si***@brunningonline.net
http://www.brunningonline.net/simon/blog/

[Christoph Zwerschke]

Tim Golden wrote:

Christoph Zwerschke wrote:

>And can somebody explain what is exactly meant with
"homogenous data"?

This seems to have been explained a few times
recently :) Basically, if you have a "list of xs"
and remove one item from it, it is still a "list of xs",

According to that definition, everything would be homogenous. I guess
what you wanted to say is if you have an "x" and remove one item from it
it is still an "x", then it's homogenous. The problem is that depending
on how exactly you define "x", you will come to different results.

If you have a tuple containing, say, a 2d coordinate pair,
and remove something from it, it's no longer a coordinate pair.

Now here comes the ambiguity. If you interpret "x" as "coordinate tuple"
it would be still one (a 1-tuple), but if you interpret "x" as
"coordinate pair" then it would indeed not be an "x" any more. So that
definition is not really helpful.

A typical example of their combined use is a set of
rows returned from a database: each row is a tuple
of fields, the same as all other such rows, and removing
or adding a field would make no sense. However, add
a new row to the list and it remains a list of rows.

Sounds plausible. But when I read a row with the name and forename of a
person, I might want to collapse the name and forename into one element
before I hand it over to a function that will display it as a table. Or
I may want to delete certain elements which are not important. In such
cases, having each row as list may also make sense.

>Concretely speaking, which data type should I use
for coordinate tuples? Usually, tuples are used. Does this mean that I
should better use lists from now on because all the components have the
same type?

This would seem to be slightly false logic (and very
possibly used tongue-in-cheek). Heterogeneous data
doesn't mean that each item *has* to be different, merely
that they *may* be.

I don't think it's a problem of false logic but the problem that
"homogenous data" is not defined.

We probably agree that it usually makes perfect sense to use tuples for
coordinates. But in certain mathematical algorithms it also makes sense
to ask for the number of zero components of a coordinate tuple - the
count() method would be helpful here.

The statement "if you are looking for index() or count() for your
tuples, you're using the wrong container type" is too extreme I think. I
would agree with "it *may indicate* that you should better use lists".

-- Christoph

[Simon Brunning]

On 12/15/06, Christoph Zwerschke <ci**@online.dewrote:

Maybe there would be less dispute if this dogma/convention(?) "Tuples
are for heterogeneous data, list are for homogeneous data" would be
written down somewhere in the tutorial, reference or in PEP8, so people
would be aware of it.

It's not a dogma. It's just that it explains the intention behind the
designs of the tuple and list APIs. If you use them for thier intended
purposes, naturally you'll find the APIs more helpful.

But you won't find the data-structure police breaking down your doors
in the small hours if you choose to go your own way[1]. I can use a
spreadsheet to write a letter if I want to - but it would be foolish
to complain that the word wrapping was a bit dodgy.

--
Cheers,
Simon B
si***@brunningonline.net

[1] The PSU, on the other hand, Mi%_$@-£+%(

[Simon Brunning]

On 12/15/06, Christoph Zwerschke <ci**@online.dewrote:

If you have a tuple containing, say, a 2d coordinate pair,
and remove something from it, it's no longer a coordinate pair.

Now here comes the ambiguity. If you interpret "x" as "coordinate tuple"
it would be still one (a 1-tuple), but if you interpret "x" as
"coordinate pair" then it would indeed not be an "x" any more. So that
definition is not really helpful.

But the new 1-tuple is no longer usable in the same contexts as the
coordinate pair. In the coordinate pair, you can infer the item's
meaning from its position.

A typical example of their combined use is a set of
rows returned from a database: each row is a tuple
of fields, the same as all other such rows, and removing
or adding a field would make no sense. However, add
a new row to the list and it remains a list of rows.

Sounds plausible. But when I read a row with the name and forename of a
person, I might want to collapse the name and forename into one element
before I hand it over to a function that will display it as a table. Or
I may want to delete certain elements which are not important. In such
cases, having each row as list may also make sense.

Sure, you can translate the tuple into a different tuple for a
different purpose, but in terms of the database, only the original
tuple (or other with the same structure) is meaningful.

The statement "if you are looking for index() or count() for your
tuples, you're using the wrong container type" is too extreme I think. I
would agree with "it *may indicate* that you should better use lists".

Oh, absolutely, it's not a hard and fast rule. But I find that if I
try to decide whether to use a tuple or a list based on lists for
homogeneous collections and tuples for heterogeneous collections where
position carries semantic meaning, then I end up using the type that
does what I need. Homogeneous collections often need to be sorted or
searched, wheras heterogeneous collections are often used as
dictionary keys.

--
Cheers,
Simon B
si***@brunningonline.net

[George Sakkis]

Christoph Zwerschke wrote:

The statement "if you are looking for index() or count() for your
tuples, you're using the wrong container type" is too extreme I think. I
would agree with "it *may indicate* that you should better use lists".

And also if that statement was correct, I would argue that Python uses
the wrong container type for storing positional arguments. More often
that not, when ones uses *varargs, he expects a homogeneous container
of extra arguments. There are exceptions of course (e.g. range()) where
each of the expected *varargs has distinct semantics, but from my
experience these are far less common than the unlimited-extra-arguments
case.

George

[Nick Maclaren]

In article <11**********************@n67g2000cwd.googlegroups .com>,
"Tim Golden" <tj******@gmail.comwrites:
|[Christoph Zwerschke]
|>
| And can somebody explain what is exactly meant with
| "homogenous data"?
|>
|This seems to have been explained a few times
|recently :) Basically, if you have a "list of xs"
|and remove one item from it, it is still a "list of xs",
|where "xs" might be people, coordinate-pairs, numbers
|or whatever made sense to you. If you have a tuple
|containing, say, a 2d coordinate pair, and remove something
|from it, it's no longer a coordinate pair. If you add one to it,
|it's something else as well (perhaps a 3d coord?)

Hmm. If I remove an object from a list of objects, does it not
remain a list of objects?

The converse is worse, as in my example. If a heterogeneous list
just happens to have objects that are all similar, does it remain
heterogeneous?

Loose guidelines are very useful, but should almost always come with
the rider "Follow these unless you have good reasons to ignore them,
but do make sure that you understand the rules first before deciding
your rules are good". Some of the responses here went a little, er,
a lot beyond that.
Regards,
Nick Maclaren.

[James Stroud]

Simon Brunning wrote:

So, you can infer no semantic meaning from an items position in the list.

[...]

The fact that an item is the nth item is a tuple *means* something.

Wouldn't it be nice, then, to find out where something is in a tuple so
that one could infer semantic meaning from its position and make
inferences about the tuple object searched, /philosophically/ speaking?
Or is the logic conveniently one-way?

James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[James Stroud]

Christoph Zwerschke wrote:

Maybe there would be less dispute if this dogma/convention(?) "Tuples
are for heterogeneous data, list are for homogeneous data" would be
written down somewhere in the tutorial, reference or in PEP8, so people
would be aware of it.

This is a good idea. It has taken me a while to begin using them in this
manner. I have been more or less forced to by the design of the language
and I confess that the intended usage of each is pretty natural.

But until this thread, I only had a latent understading of their
intended use. Now it is much clearer to me, though it seems kind of
late. I don't think an explicit explanation is in Learning Python (which
is the book I used to learn python).

It seems like such an fundamental principle should be in *all* of the
introductory texts, much like the process for defining a function is in
all introductory texts. I don't think PEPs, the language reference, or
inclusion in a single introductory text somewhere would be enough for
one to point at and say "you should have read this".

(Well, I'm in the process of reading the internet right now, but I just
haven't gotten to PEP 646 or python-dev from 1993. I estimate I'll get
to these in a few dozen years.)

If I recall correctly, Learning Python emphasized the practical
differences between tuples and lists and did not elaborate on the
philosophy of their usage. I seem to remember an emphasis on efficiency
and how tuples hold an advantage.

And can somebody explain what is exactly meant with "homogenous data"?
That the type of the elements is the same in some technical or
philosophical meaning?

Hopefully homogenous means that all of the objects in the list share a
common interface. To enforce this interface would require the interface
definition in the initialization of a list, etc., which would not be
consistent with python duck typing and would require that interfaces be
added to the language.

Concretely speaking, which data type should I use
for coordinate tuples? Usually, tuples are used. Does this mean that I
should better use lists from now on because all the components have the
same type?

I don't think that all homogenous structures should be lists. This is
not the same as saying that all lists should be homogenous.

James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[Hendrik van Rooyen]

"Christoph Zwerschke" <ci**@online.dewrote:

I don't think it's a problem of false logic but the problem that
"homogenous data" is not defined.

We probably agree that it usually makes perfect sense to use tuples for
coordinates. But in certain mathematical algorithms it also makes sense
to ask for the number of zero components of a coordinate tuple - the
count() method would be helpful here.

The statement "if you are looking for index() or count() for your
tuples, you're using the wrong container type" is too extreme I think. I
would agree with "it *may indicate* that you should better use lists".

>From a practical point of view, the only reason to use a tuple instead

of a list for anything seems to be that you want to use it as a key in a dict...

Otherwise, why bother with these recalcitrant things that you can't
change or index, or append to or anything that lists allow?

- Hendrik

[Christoph Zwerschke]

Hendrik van Rooyen wrote:

From a practical point of view, the only reason to use a tuple instead
of a list for anything seems to be that you want to use it as a key in a dict...

Otherwise, why bother with these recalcitrant things that you can't
change or index, or append to or anything that lists allow?

I can imagine (but don't know whether this is actually the case in
CPython) that tuples have some memory and/or performance advantages over
lists, and there could be special optimizations for small (2 or 3
element) tuples because they are used very frequently.

So that would be another practical aspect why a long list of tuples
could be better than a long list of lists - but does anybody know
whether this is even true for CPython?

-- Christoph

[Christoph Zwerschke]

James Stroud wrote:

Christoph Zwerschke wrote:

>Maybe there would be less dispute if this dogma/convention(?) "Tuples
are for heterogeneous data, list are for homogeneous data" would be
written down somewhere in the tutorial, reference or in PEP8, so
people would be aware of it.

This is a good idea. It has taken me a while to begin using them in this
manner. I have been more or less forced to by the design of the language
and I confess that the intended usage of each is pretty natural.

I just found that there is indeed some mentioning in the FAQ here:
http://www.python.org/doc/faq/genera...ist-data-types
But it is a bit vague, too, and does not mention whether there is any
difference in efficiency which would be interesting to know as well.

It would be nice if somebody with more knowledge about the internals
could overhaul and supplement that answer in the FAQ. A link to this in
the tutorial or other parts of the standard doc where tuples and lists
are discussed would be also helpful.

>Concretely speaking, which data type should I use for coordinate
tuples? Usually, tuples are used. Does this mean that I should better
use lists from now on because all the components have the same type?

I don't think that all homogenous structures should be lists. This is
not the same as saying that all lists should be homogenous.

So in which cases exactly should one make exceptions? Python experts
probably decide this from their "gut feelings" but it would be nice to
have a more complete "rule of thumb" or decision guidance for
non-experts that is mentioned somewhere in the docs, too:

Must be hashable for use as dict key or set element --tuple
"Inhomogenous" in some meaning of the word --tuple
.... (fill in the details) --tuple
everything else --list

Maybe we can agree on something concrete here.