terminological obscurity

[Colin J. Williams]

I think the fact that Python lists can be heterogogenous is one
of the most brilliantly useful things in the language, but
apparently we're not supposed to use lists like that.

It's not heterogeneity of type you're supposed to avoid, it's
heterogeneity of purpose. That is, you should be intending to treat
each cell of the list similarly.
[/QUOTE]
Section 3.2 of the Python Reference Manual has
Tuples: The items of a tuple are arbitrary Python objects.
Lists: The items of a list are arbitrary Python objects.

The generality of that seems clear. Can we not leave 'purpose' to a
book of best practices?

Colin W.

 

[Donn Cave]

Quoth Arthur <[email protected]>:
....
| I think I am perfectly capable of making sense of the explanation
| that uses the unambigous words heterogenous and homogenous in the
| context of this discussion.
|
| But the ambiguous word in the previous sentence, IMO, is
| "explanation". Because in the end - I am repeating myself - I find,
| with emphasis given these words - a tautolofgy parading as an
| explanation.

If repetition works for you, let's go back and give it the works.
You first announced this conclusion in a followup to Shalabh
Chaturvedi. Here is the account of homogeneity in that post:

Chaturvedi:
I believe it is conceptual homogeneity and not type homogeneity that
characterises the difference between lists and tuples.

Consider use of tuples such as (hostname, port) or (firstname, lastname,
middleinitial) or (x_coordinate, y_coordinate). In all cases you *know*
what the first element means, what the second element means etc. It is
usually not useful to find a value since the different values mean
different things. You might rather do this something like - if host_port[1]
== 80:...

Can you quote _both paragraphs_ of the above and point out the
circularity in his explanation?

I don't know if homogeneity is the most useful term to get at the
distinction as I understand it, but evidently that's how Guido tried
to explain it, so that's where we start. It can take some explaining.
We could try to think of better ways to approach it - maybe bring in
the notion of a tuple as a "product" of its elements - but the parties
to that discussion would have to 1) understand the distinction, and
2) not be satisfied with the way it's currently explained. No sign
of anyone in that corner yet.

Donn Cave, (e-mail address removed)

 

[Arthur]

Consider use of tuples such as (hostname, port) or (firstname, lastname,
middleinitial) or (x_coordinate, y_coordinate). In all cases you *know*
what the first element means, what the second element means etc. It is
usually not useful to find a value since the different values mean
different things. You might rather do this something like - if host_port[1]
== 80:...

Can you quote _both paragraphs_ of the above and point out the
circularity in his explanation?

Given a tuple (1,1,1) representing X,Y,Z corrdinates, I - for one -
have trouble explaining the heterogenous nature of the data, outside
of the "tuple" sense of the word.

Similarly, "conceptual homogeniety" in this context can mean anything
- to me, pretty much -, within the limit of describing data elements
that it might be sensible to handle together in a list.

I don't know if homogeneity is the most useful term to get at the
distinction as I understand it, but evidently that's how Guido tried
to explain it, so that's where we start. It can take some explaining.
We could try to think of better ways to approach it - maybe bring in
the notion of a tuple as a "product" of its elements - but the parties
to that discussion would have to 1) understand the distinction, and
2) not be satisfied with the way it's currently explained. No sign
of anyone in that corner yet.

The best reason to describe the current explanations as a tautology,
is precsiely because it can only really be understood as a meaningful
explanation to those who don't really need one. It does little, in my
opinion, to serve as help for those who might.

Especially, or at least, outside the context of a ten or more post
thread of the dialetics.

Art

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

I think the fact that Python lists can be heterogogenous is one
of the most brilliantly useful things in the language, but
apparently we're not supposed to use lists like that. Since
tuples aren't mutable, I'm completely at a loss as to how we're
supposed to deal with mutable heterogenous sequences.

You should define classes.

Regards,
Martin

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Given a tuple (1,1,1) representing X,Y,Z corrdinates, I - for one -
have trouble explaining the heterogenous nature of the data, outside
of the "tuple" sense of the word.

Most people tend to think that "height" and "width" are different
concepts. I am 199cm high, not 199cm wide. So my extension, in Y
direction, is 199cm - not my X extension, nor my Z extension.

The fact that I use cm to measure X, Y, and Z still doesn't make
them homogenous. If they were homogenous, I could add many more
of these in a meaningful way (yes, I know that some people have
applications where you process arbitrary numbers of coordinates.
typically, 2D, 3D, and 4D are entirely different things).

Similarly, "conceptual homogeniety" in this context can mean anything
- to me, pretty much -, within the limit of describing data elements
that it might be sensible to handle together in a list.

A collection of data is homogenous if their relative position in
the sequence does not matter much. They are heterogenous if different
elements have entirely different meanings.

Regards,
Martin

 

[Aahz]

I think the fact that Python lists can be heterogogenous is one of the
most brilliantly useful things in the language, but apparently we're
not supposed to use lists like that. Since tuples aren't mutable, I'm
completely at a loss as to how we're supposed to deal with mutable
heterogenous sequences. C always required tons of extra work to do
stuff like that -- creating unions of structures with common header
fields to tell you what type of union it was and so on.

It's a *guideline*, not an iron-clad restriction. Python is a language
for consenting adults, after all. Part of the point is that it rarely
makes sense to have an immutable homogenous collection.

 

[Arthur]

The fact that I use cm to measure X, Y, and Z still doesn't make
them homogenous.

A question on some IQ test:

X,Y & Z rerpesent the 3d coordinates of a point in some coordinate
system.

X=1
Y=1
Z=1

The ordred seqence (1,1,1) of the X,Y & Z coordinates represents

a) heterogenous data
b) homogenous data
c) N/A

has a right answer.

A.

I disagree.

Regards,

Art

 

[Mel Wilson]

A question on some IQ test:

X,Y & Z rerpesent the 3d coordinates of a point in some coordinate
system.

X=1
Y=1
Z=1

The ordred seqence (1,1,1) of the X,Y & Z coordinates represents

a) heterogenous data
b) homogenous data
c) N/A

has a right answer.

A.

I disagree.

Depends on the coordinate system. If the bases are east,
north and up, then you're right to disagree. If they're
east, up and future, then you're also right although the
argument is subtle. If they're height, weight and Nielsen
Rating, then A may be the best answer.

Regards. Mel.

 

[Peter Hansen]

Depends on the coordinate system. If the bases are east,
north and up, then you're right to disagree. If they're
east, up and future, then you're also right although the
argument is subtle. If they're height, weight and Nielsen
Rating, then A may be the best answer.

What's the inherent difference between the (east, up, future)
coordinate system and the (height, weight, Nielsen Rating)
one that makes the argument subtle in one case, but wrong in
the other?

-Peter

 

[Donn Cave]

Quoth Arthur <[email protected]>:
| >
|> Consider use of tuples such as (hostname, port) or (firstname, lastname,
|> middleinitial) or (x_coordinate, y_coordinate). In all cases you *know*
|> what the first element means, what the second element means etc. It is
|> usually not useful to find a value since the different values mean
|> different things. You might rather do this something like - if host_port[1]
|> == 80:...
|>
|> Can you quote _both paragraphs_ of the above and point out the
|> circularity in his explanation?
|
| Given a tuple (1,1,1) representing X,Y,Z corrdinates, I - for one -
| have trouble explaining the heterogenous nature of the data, outside
| of the "tuple" sense of the word.

I don't know what you mean by `outside the "tuple" sense of the word",
but in a way I think that may be nearly the problem. Of course if you
consider these objects on their own, the contents of the tuple but
isolated from that context, they're as homogeneous as you could want,
in fact they would be the very same object.

But (I hope) no one articulating this point of view says "homogeneous
data", or "homogeneous contents", etc. Of course the very same objects
could occur in two separate sequences, one homogeneous and the other
heterogeneous. This point is that the tuple itself is heterogeneous,
each element having a separate non-interchangeable role; the list is
homogeneous, having at most some sort order. The objects don't express
this on their own, it's a property of the sequence.

|> I don't know if homogeneity is the most useful term to get at the
|> distinction as I understand it, but evidently that's how Guido tried
|> to explain it, so that's where we start. It can take some explaining.
|> We could try to think of better ways to approach it - maybe bring in
|> the notion of a tuple as a "product" of its elements - but the parties
|> to that discussion would have to 1) understand the distinction, and
|> 2) not be satisfied with the way it's currently explained. No sign
|> of anyone in that corner yet.
|
| The best reason to describe the current explanations as a tautology,
| is precsiely because it can only really be understood as a meaningful
| explanation to those who don't really need one. It does little, in my
| opinion, to serve as help for those who might.

Well, I don't know if anyone really needs an explanation, and I'm
struggling with my understanding of "tautology" to fit it in here,
but there is something to what you say. It's kind of a Python nerd
topic, not a key that's going to unlock the waiting potential of the
language.

But for me, I know I didn't get it on my own at first. I tended to
use tuples as a `more efficient' sequence type. I think the impetus
to reform my thinking came from here, and I think nerd chatter like
this does serve some purpose.

Donn Cave, (e-mail address removed)

 

[Arthur]

I don't know what you mean by `outside the "tuple" sense of the word",
but in a way I think that may be nearly the problem. Of course if you
consider these objects on their own, the contents of the tuple but
isolated from that context, they're as homogeneous as you could want,
in fact they would be the very same object.

But (I hope) no one articulating this point of view says "homogeneous
data", or "homogeneous contents", etc.

http://mail.python.org/pipermail/python-dev/2003-March/033964.html

Qutoeth Guido:

"Tuples are for heterogeneous data, list are for homogeneous data."

I have been trying to stict meticulously to his terminology, because
my understanding is that is why it is being used.

Lists are for homogenous data, with homogenous data defined as data
that under some cricumstance might be sensibly used in a list.

I routinely use lists to hold instances of different classes.

The classes in the lists are fully homogenous.

I wrote them all

Art

 

[Arthur]

http://mail.python.org/pipermail/python-dev/2003-March/033964.html

Qutoeth Guido:

"Tuples are for heterogeneous data, list are for homogeneous data."

With the next epicycle needed to save the phenonenon perhaps being to
suggest that I am distorting his meaning

by quoting him percisely.

But the truth is I am open to intepretations. Though I suspect I've
heard the range, by now.

Art

 

[Donn Cave]

Quoth Arthur <[email protected]>:
| On Sun, 23 May 2004 16:13:14 -0000, "Donn Cave" <[email protected]>
| wrote:
|
|> I don't know what you mean by `outside the "tuple" sense of the word",
|> but in a way I think that may be nearly the problem. Of course if you
|> consider these objects on their own, the contents of the tuple but
|> isolated from that context, they're as homogeneous as you could want,
|> in fact they would be the very same object.
|>
|> But (I hope) no one articulating this point of view says "homogeneous
|> data", or "homogeneous contents", etc.
|
|
| http://mail.python.org/pipermail/python-dev/2003-March/033964.html
|
| Qutoeth Guido:
|
| "Tuples are for heterogeneous data, list are for homogeneous data."
|
| I have been trying to stict meticulously to his terminology, because
| my understanding is that is why it is being used.

It's too bad if he said that. I think it has not led to mass confusion
because if one interpretation of that 10 word summary makes it an utterly
absurd proposition, most people are inclined to give him enough credit
to look for another interpretation.

I'm sure there has been enough discussion of this by now for anyone
who cared, but I can't resist a final observation. Suppose we take
the absurd interpretation, and further decide to implement a test
for this condition, where we evaluate a sequence's homogeneity by
comparing its contents object by object. Whatever the original
sequence may be, I can tell you right now that the natural sequence
type for object by object operations on its contents will be a list.
We're going to be very nearly sorting the data, in fact might use
sort() to start with if we're lazy, and that's a list operation.
Now since lists are for homogeneous data, and this is clearly an
application for a list, it can be seen that all sequences are
homogeneous, and tuples have no valid use!

There's your circular explanation.

Donn Cave, (e-mail address removed)

 

[Arthur]

It's too bad if he said that. I think it has not led to mass confusion
because if one interpretation of that 10 word summary makes it an utterly
absurd proposition, most people are inclined to give him enough credit
to look for another interpretation.

We agree as to the dynamics at work.

But seem to have different feelings about it.

I honestly don't know what he meant here, or how seriously he meant
it.

But there have been other instances, on other issues, where it has
been clearer to me what he meant. Some of those issues were of more
significance, to me, than this. And guess what, it was my conclusion
that he was simply and utterly wrong. And felt myself to be arguing
within a community that seemed to find it necessary to find him right,
by any means necessary.

Even where it took the form, in my eyes, of bizarre contortions and
the defiance of common sense

It - as I had said at the time - gave me the willies.

Art

 

[Grant Edwards]

Lists are for [...] data that under some cricumstance might be
sensibly used in a list.

My amusement at the above statement aside, I think I do get it
now:

Tuples are for when you should have used a structure with
symbolically named fields.

 

[Arthur]

We agree as to the dynamics at work.

With some part of that dynamics, it seems to me, being that many of us
take our own understanding of the difference between tuples and lists
(some of which might be deeper than others, mine on the lighter side)
and then ascribe and reconcile that understanding with Guido's words.
Which is part of the tautaology factor.

It works fine, until we try to communicate with each other, around
those words.

Art

 

[Arthur]

With some part of that dynamics, it seems to me, being that many of us
take our own understanding of the difference between tuples and lists
(some of which might be deeper than others, mine on the lighter side)
and then ascribe and reconcile that understanding with Guido's words.
Which is part of the tautaology factor.

Sorry folks, the dunamics here really interest me. It is simply group
dynamics in the circumstances of a strong individual leader. I don't
mean to be in finger pointing, or hysterics mode.

But backing up, and re-reading the python-dev thread from which this
all starts, I think there is one other factor.

Simply that the distinction being drawn by Guido was - I'm thinking -
formed prior to new style classes, and attendent changes to the
language. And that it was more meaningful once, than it is now is.

Certainly a programming language like Python is tightly woven and it
should be no real surprise that changes to the language as fundamental
as occurred since 1.5.2 - not directly related to lists or tuples -
would impact the conceptualization and language with which might most
appropriate in describing these structures.

I am going out of on a limb (I've long since had little to lose by
doing so here) - and beyond by competence - to speculate that part of
what we have here is a time warp in the direction reverse from which
is normally expected of Guido.

Art

 

[Donn Cave]

....

We agree as to the dynamics at work.

But seem to have different feelings about it.

I honestly don't know what he meant here, or how seriously he meant
it.

But there have been other instances, on other issues, where it has
been clearer to me what he meant. Some of those issues were of more
significance, to me, than this. And guess what, it was my conclusion
that he was simply and utterly wrong. And felt myself to be arguing
within a community that seemed to find it necessary to find him right,
by any means necessary.

I may have been there, I sure remember other occasions where
the two of you differed over things. I have too, and the way
I remember it, I have taken your side as often as not. But
it's never a case of `simply and utterly wrong', there's always
some question of judgement in there. One never knows, but
there's some reason to think that I'm not vastly smarter than
everyone else, so it's prudent and generally more effective
to look pretty hard for the sense in what I disagree with.

Donn Cave, (e-mail address removed)

 

[Donn Cave]

Sorry folks, the dunamics here really interest me. It is simply group
dynamics in the circumstances of a strong individual leader. I don't
mean to be in finger pointing, or hysterics mode.

But backing up, and re-reading the python-dev thread from which this
all starts, I think there is one other factor.

Simply that the distinction being drawn by Guido was - I'm thinking -
formed prior to new style classes, and attendent changes to the
language. And that it was more meaningful once, than it is now is.

Certainly a programming language like Python is tightly woven and it
should be no real surprise that changes to the language as fundamental
as occurred since 1.5.2 - not directly related to lists or tuples -
would impact the conceptualization and language with which might most
appropriate in describing these structures.

That's reasonable, but can you explain your hypothesis?
Like, what is it about the current class/type structure
that has anything to do with this? I don't see it.

As far as the group dynamics & Guido go, you can probably
forget that. There are all kinds of things going on, and
that could play a role, but only a weak one. People have
a lot of strong opinions about programming languages, and
if people here seem to find it easy to agree with Guido,
the simplest explanation is that they choose to use Python
and hang out on comp.lang.python because they like it. As
long as he keeps singing basically the same tune, they'll
like what they hear. If he were to take off in some really
different direction - like imagine he announces that Python 3
will have strong static typing - the majority would be
outraged and the rest would be the minority who always did
wish that were the case.

In fact I think this has something to do with the present
issue - the notion of a homogeneous list is very familiar
to users of statically typed languages, where it means exactly
what it wasn't supposed to mean here. To a defender of the
faith, them's fightin' words, regardless of who said it.

Donn Cave, (e-mail address removed)

 

[Aahz]

Tuples are for when you should have used a structure with
symbolically named fields.

More precisely, when you have symbolic fields, but you want a
light-weight and immutable structure to contain the info.