terminological obscurity

[Grant Edwards]

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

Well put.

The immutable part is also important because that means they
can be used as keys in a dictionary -- even if they are
homogeneous.

 

[Christos TZOTZIOY Georgiou]

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.

Well, lists, tuples, homogenity etc in other words (mine):

Take a sequence of items. If there is a point in comparing an item of
the sequence to another, use a list. If not, use a tuple.

You can stop reading here.

Digression: if you want to mark a specific point in time, use a tuple of
(hour, minute, second). Do you care if hour > minute? If m is such a
tuple, does m.sort() have any meaning?

More digression:

Tuple: a poor man's record.

Take a function with arguments name, age. Consider this name, age as a
tuple, since calling the function with the age first and then the name
quite probably will produce garbage (please don't reply using an example
of named arguments). The order is important; t[0] is the name, t[1] is
the age.

List: generic sequence.

Take a function taking a sequence of fruits. You may want to know how
many yellow fruits you have, or maybe you want to add their weights and
find the average. Use a list; it doesn't matter if you call the
function with an argument of [banana, orange, apple] or [orange, apple,
banana]. It's equivalent. l[0] is a fruit, l[1] is another fruit, and
so on.

I'm just trying to make you see it as simple as I see it. Did I
succeed? If not, then I beg your pardon in advance. If yes, I'm glad.

Of course, you can always use a list instead of a tuple in all cases,
with the minor exception of using a tuple when you want to index a
mapping.

 

[Grant Edwards]

Take a sequence of items. If there is a point in comparing an item of
the sequence to another, use a list. If not, use a tuple.

You can stop reading here.

Unless you want to use it as a key for a dictionary. Then use
a tuple.

Of course, you can always use a list instead of a tuple in all cases,
with the minor exception of using a tuple when you want to index a
mapping.

 

[Arthur]

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.

Well for one, before new style classes, it was easier to think of an
"instance" as in some sense a pseudo data type. Instances of
different classes - even with no hierarchical relationship - were more
conceptually homogenous.

But with everything subclassable, 2 different classes, each derived
from object, are conceptually distinguished more similarly to the way
in which a str and int are distinguished.

So in quoteth Guido from the same thread:

GvR> I always think of the type of a list as "list of T" while I
GvR> think of a tuple's type as "tuple of length N with items of
GvR> types T1, T2, T3, ..., TN". So [1, 2] and [1, 2, 3] are both
GvR> "list of int" (and "list of Number" and "list of Object", of
GvR> course) while ("hello", 42) is a "2-tuple with items str and
GvR> int" and (42, "hello", 3.14) is a "3-tuple with items int,
GvR> str, float".

He sort of stacks the cards by making his tuples of hetereogenous
type, and his list easily described as a list of T. And thereby
sidesteps all the ambiguities inherent in the ten word edict. Except
that at the Object level, we are at lists of Objects and tuples of
Objects. It detracts little from the point of the above quote, but
this quote then becomes substantially weaker as support for his 10
worder.

Is the best I can express 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.

I like Python and choose to hang on Python list, and find it easy to
disagree with Guido. But that only occurs head-on when he ventures
into non-technical areas were I consider the playing field more even.
And this depsite the fact I would have no problem granting him a
higher IQ. Since I have lived in close quarters with higher IQs, and
have a pretty developed sense, I think, of what that buys you, and
what it doesn't.

Art

 

[Arthur]

So in quoteth Guido from the same thread:

GvR> I always think of the type of a list as "list of T" while I
GvR> think of a tuple's type as "tuple of length N with items of
GvR> types T1, T2, T3, ..., TN". So [1, 2] and [1, 2, 3] are both
GvR> "list of int" (and "list of Number" and "list of Object", of
GvR> course) while ("hello", 42) is a "2-tuple with items str and
GvR> int" and (42, "hello", 3.14) is a "3-tuple with items int,
GvR> str, float".

He sort of stacks the cards by making his tuples of hetereogenous
type, and his list easily described as a list of T.

And of course by making his tuples of the same data type and his lists
example let's say say more challenging, he would have thereby
implicitly accepted the challenge of defending the wroding of his
edict, it all its subtlety.

He chose not to, big time.

The fact that others have accepted that challenge is welcome.

That they choose to do so explicitly on his behalf, is - to me -
peculiar.


Art

 

[Fredrik Lundh]

Well for one, before new style classes, it was easier to think of an
"instance" as in some sense a pseudo data type. Instances of
different classes - even with no hierarchical relationship - were more
conceptually homogenous.

nonsense. Python has always used duck typing (what's important is what
you can do with x, not what type(x) happens to be). this hasn't changed a
bit.

(if you don't understand duck typing, you don't really understand Python)

</F>

 

[Fredrik Lundh]

And of course by making his shoes of the same data type and his sandal
example let's say say more challenging, he would have thereby
implicitly accepted the challenge of defending the wroding of his
edict, it all its subtlety.

He chose not to, big time.

The fact that others have accepted that challenge is welcome.

That they choose to do so explicitly on his behalf, is - to me -
peculiar.

replace tuples and lists with shoes and sandals, and this thread plays like a
scene from the "the afterlife of brian, revisisted" documentary by cristopher
guest.

narrator: "when we meet him 40 years later, Arthur's still hasn't gotten over
that shoe incident"

flashback: http://bau2.uibk.ac.at/sg/python/Scripts/LifeOfBrian/brian-17.html

</F>

 

[Arthur]

nonsense. Python has always used duck typing (what's important is what
you can do with x, not what type(x) happens to be). this hasn't changed a
bit.

(if you don't understand duck typing, you don't really understand Python)

</F>

Nonsense.

I understand Python - but at a practical user level. If understanding
it at that level isn't under5staning it, than it is not what it claims
to be.

Art

 

[Arthur]

replace tuples and lists with shoes and sandals, and this thread plays like a
scene from the "the afterlife of brian, revisisted" documentary by cristopher
guest.

And I keep thinking this is a thread about homogenous and
hetereogenous.

Tuples and lists are easy.

dir( () )

vs.

dir( [] )

There is no doubt in my mind that I am *using* lists correctly, where
there is something esssential I need that I find with dir( [] ) and
don't find with dir( () ).

Art

 

[Donn Cave]

Well for one, before new style classes, it was easier to think of an
"instance" as in some sense a pseudo data type. Instances of
different classes - even with no hierarchical relationship - were more
conceptually homogenous.

But with everything subclassable, 2 different classes, each derived
from object, are conceptually distinguished more similarly to the way
in which a str and int are distinguished.

Really makes no difference at all - not just insignificant,
really _no_ difference. A truly heterogeneous sequence may
be full of references to the _same_ object (e.g., (1, 1, 1)),
and a truly homogeneous sequence may have objects as different
as None and a module. It's not about properties of the objects,
considered in isolation.

GvR> I always think of the type of a list as "list of T" while I
GvR> think of a tuple's type as "tuple of length N with items of
GvR> types T1, T2, T3, ..., TN". So [1, 2] and [1, 2, 3] are both
GvR> "list of int" (and "list of Number" and "list of Object", of
GvR> course) while ("hello", 42) is a "2-tuple with items str and
GvR> int" and (42, "hello", 3.14) is a "3-tuple with items int,
GvR> str, float".

He sort of stacks the cards by making his tuples of hetereogenous
type, and his list easily described as a list of T. And thereby
sidesteps all the ambiguities inherent in the ten word edict. Except
that at the Object level, we are at lists of Objects and tuples of
Objects. It detracts little from the point of the above quote, but
this quote then becomes substantially weaker as support for his 10
worder.

Guess he may have overestimated his audience.

If you're interested in the history of this matter, it may
help to know that Guido did not invent the tuple. It has
been around in computer programming languages since Lisp.
You can actually find precisely parallel descriptions of
the concept in that context, down to the unnecessary use
of different data types to emphasize the heterogeneity.

Lisp and its relatives have both a tuple and a list type,
but the list is a `real list', not a 1-dimension array as
in Python but a recursive data structure. In Python, this
data structure can be represented using a tuple:

t = (0, None)
t = (1, t)
t = (2, t)
...
def print_list(tail):
value, tail = tail
if tail:
print_list(tail)
print value

Guido's "mistake" is that unification of all these sequence
types leaves the distinctions less obvious.

Donn Cave, (e-mail address removed)

 

[Arthur]

Donn -

First let me thank you for engaging me. I have learned some, and it
has allowed me to express myself some.

Really makes no difference at all - not just insignificant,
really _no_ difference. A truly heterogeneous sequence may
be full of references to the _same_ object (e.g., (1, 1, 1)),
and a truly homogeneous sequence may have objects as different
as None and a module. It's not about properties of the objects,
considered in isolation.

You fundamentally miss my point.

What you are saying is clear enough. You are also saying that this is
what Guido meant, when he said something different. And leaving as
anomolous why Guido didn't say what he meant himself.

I am connecting 2 points by a straight line, rather by way of an
occult labyrinth. I am suggesting the possbility that Guido's
expressed himself ambigously, because the matter wasn't as crsiply
defined in his own mind as it is in yours.

The part I consider to be pure, but plausible speculation, is why that
might have been true. That at an earlier point in Python's
development, the distinction between homogenous data and a homogenous
sequence was not crucial to draw, and that Guido therrfore hadn't
drawn it.

Guess he may have overestimated his audience.

True.

Not everyone can map from what he said to what he meant in the way you
can

If you're interested in the history of this matter, it may
help to know that Guido did not invent the tuple. It has
been around in computer programming languages since Lisp.
You can actually find precisely parallel descriptions of
the concept in that context, down to the unnecessary use
of different data types to emphasize the heterogeneity.

Lisp and its relatives have both a tuple and a list type,
but the list is a `real list', not a 1-dimension array as
in Python but a recursive data structure. In Python, this
data structure can be represented using a tuple:

t = (0, None)
t = (1, t)
t = (2, t)
...
def print_list(tail):
value, tail = tail
if tail:
print_list(tail)
print value

Guido's "mistake" is that unification of all these sequence
types leaves the distinctions less obvious.

Maybe your grasp of this history could help explain things, on the
slight possiblity that there is some merit my suggestion that you are
clearer of these issues than Gudio had been in March of 2003,

Art

 

[Donn Cave]

Quoth Arthur <[email protected]>:
| On Tue, 25 May 2004 09:03:29 -0700, Donn Cave <[email protected]>
| wrote:
...
| You fundamentally miss my point.
|
| What you are saying is clear enough. You are also saying that this is
| what Guido meant, when he said something different. And leaving as
| anomolous why Guido didn't say what he meant himself.

Well, to be honest, what Guido said or meant isn't the critical thing
for me. But this isn't a choice between two reasonable alternatives.
He did distinguish between the ideal applications for tuples and lists,
describing them in terms that allow for one sensible interpretation,
and one completely, utterly absurd interpretation.

Maybe he could have said it better, seeing as some people read it and
don't get the sensible interpretation right away. So they say `hey,
what's up with this weird idea about lists vs. tuples?' For most,
this seems to be a solvable problem. I don't know if everyone is
convinced of the merits of the argument, but they at least roughly
understand it. You, however, start from the observation that Guido
said something bafflingly stupid, and then proceed to cling to that
interpretation when everyone else has dismissed it. Why? Don't
answer that, I don't care. Just forget about Guido for a while, OK?
If you are constructing a conceptually homogeneous sequence, use a
list.

Donn Cave, (e-mail address removed)

 

[Arthur]

Just forget about Guido for a while, OK?

My beef with the discussions on Python list surrounding the
distinction between tuples and lists has never been with Guido.
Though it isn't possbile to try to express that beef without his name
coming up.

If you are constructing a conceptually homogeneous sequence, use a
list.

Always have, always will.

Art

 

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

Really makes no difference at all - not just insignificant,

You fundamentally miss my point.

What you are saying is clear enough. You are also saying that this is
what Guido meant, when he said something different. And leaving as
anomolous why Guido didn't say what he meant himself.

What he did say is

"Tuples are for heterogeneous data, list are for homogeneous data.
Tuples are *not* read-only lists."

He did not actually define the terms that he was using (just as
he did not define the terms tuple, list, data, or read-only).

It is very clear to my why he did not say what Donn said - because
he thought that the notion of homogenous and heterogenous is obvious
to anybody.

He then *also* said something about how static typing might be
introduced into Python - but that was about possible static typing,
not about the terms "homogenous" and "heterogenous". Even with
static typing, it might be possible to declare a list that is
statically typed, contains homogenous data, and yet contains
objects as different as None and a module. The type of this
list might be "list of (NoneType union ModuleType)", better
declared as "list of optional ModuleType".

Regards,
Martin

 

[Arthur]

It is very clear to my why he did not say what Donn said - because
he thought that the notion of homogenous and heterogenous is obvious
to anybody.

FIRST
-------------------------------------------------------------------------------------------------------
The name of our thread is "terminological obscurity". And I expect
that the orignal poster had as good a grasp as you (or I) as to the
meaning of homogenous and heterogenous.

And it is certainly easy for Martin or Donn to assume that we are
talking technically over the head of someone like myself. I'll go
fuirther and allow us to assume that is part of what is going on.

Another part of what is going on has nothing to do with that at all.
It is about lnaguage and it is about logic and it is about the
dynamics of groups.

My involvement in this discussion began in reaction to a statment made
to the typical question about why tuples *and* lists are in the
language:

Assume """ surrounds *exact* quotes from the newsgropup.

"""
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.
"""

and in defense of a challange to this statement based on the
flexibility of Python of handling data of different types in a list,
came this response:

"""
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.
"""

So that, in effect, was the first time I was told that the problem is
I don't understand what Guido meant, i.e. I didn't understand that
lists were designed to be used " with homogenous members, that is
weith members of the same type".

Thankfully Donn interceded at that point to bring the dicussion more
onto a sensible track.

And as a result:

We all agree, (do we not) at this point - even the poster of these
remarks - if that is what Guido in fact meant, I was doing good not
to understand him, (or believe him if I did.)

SECOND
-------------------------------------------------------------------------------------------------------------
When Donn thought the terminology "homogenous data" and "hetereogenous
data" in the context of the discussionss were coming from me, or other
"unofficial" sources, he implied strongly that the use of this
terminology was part of what was creating some misunderstanding of the
concepts involved.

When I told him the terminology was not mine, but Guido's my lack of
understanding (that being the constant) now became that I didn't
understand what Guido meant when he used the terminology which was a
moment ago unacceptable. That is the second time I was told the
problem was *my* capacity to understand what Guido meant.

He then *also* said something about how static typing might be
introduced into Python - but that was about possible static typing,
not about the terms "homogenous" and "heterogenous". Even with
static typing, it might be possible to declare a list that is
statically typed, contains homogenous data, and yet contains
objects as different as None and a module. The type of this
list might be "list of (NoneType union ModuleType)", better
declared as "list of optional ModuleType".

THIRD
-------------------------------------------------------------------------------------------------------------

Donn. who I think we agree, brought some light to this discussion did
state clearly, I think, that the use of the "homogenous data" (in
describing for example None and a module) is bad and misleading
terminolgy. Perhaps, because it supports too well a supposition that
we are only talking in tautologies. What can be said be homogenous
about such data, outside of the membership in a list? Donn suggests
the list is homogenous, even if the data is not, in any meaningful
sense. I think I understand that a bit.

Yet you insist, with a fresh start on all this, on using the
terminology "homogenous data".

I don't understand Martin any better thatn I understand Guido.

In fact I am totally lost.

Art

 

[Arthur]

Yet you insist, with a fresh start on all this, on using the
terminology "homogenous data".

I only see 3 possibilities:

1. You are going further than Donn and Michael Chermside, who
maintained that Guido meant exactly what should be meant, but didn't
express it well. Are you saying that Guido meant exactly what should
be meant, and expressed it as it should be expressedl - and that Donn
and Michael are also missing something (perhaps more subtle than what
I am missing)?

2. You are using the same terminology, now in a different sense.

3. You are expressing some sense that this issue as to terminology
doesn't interest you - as long as you and Guido know what you and
Guido mean.

Art

 

[Michael Geary]

Arthur... May I offer you a nice glass of homogenized milk?

Enjoy!

-Mike

 

[Donn Cave]

Quoth Arthur <[email protected]>:
| On Thu, 27 May 2004 19:30:40 +0200, "Martin v. Löwis"
|>
|> It is very clear to my why he did not say what Donn said - because
|> he thought that the notion of homogenous and heterogenous is obvious
|> to anybody.
....
| ... That is the second time I was told the
| problem was *my* capacity to understand what Guido meant.

Well, I'm unable to see such problems in any other terms. Understanding
is limited by capacity to understand, certainly.

|> He then *also* said something about how static typing might be
|> introduced into Python - but that was about possible static typing,
|> not about the terms "homogenous" and "heterogenous". Even with
|> static typing, it might be possible to declare a list that is
|> statically typed, contains homogenous data, and yet contains
|> objects as different as None and a module. The type of this
|> list might be "list of (NoneType union ModuleType)", better
|> declared as "list of optional ModuleType".

| Donn. who I think we agree, brought some light to this discussion did
| state clearly, I think, that the use of the "homogenous data" (in
| describing for example None and a module) is bad and misleading
| terminolgy. Perhaps, because it supports too well a supposition that
| we are only talking in tautologies. What can be said be homogenous
| about such data, outside of the membership in a list? Donn suggests
| the list is homogenous, even if the data is not, in any meaningful
| sense. I think I understand that a bit.

Good! You're too generous, but it's good of you to spell my name right.

| Yet you insist, with a fresh start on all this, on using the
| terminology "homogenous data".

Oh, well. You knew what he meant, though, didn't you? Note that
the passage above describes a slightly different homogeneity.
This list still contains a module and a None, but now some
arrangement has been made to give them each the same type, when
before they were of completely disparate types (and still are.)

Well, I'm not really sure what he has in mind there, so there
is some ambiguity for students of homogeneity such as ourselves.
I'm convincing myself though that this type information does
least for practical purposes become a property of the object,
so they are indeed homogeneous considered on their own. In some
way.

In some languages with strong static typing, such as Haskell or
ML, you'd use a parameterized `algebraic' type sort of like

type option a = Some a | Nothing

This is essentially a wrapper, a package from which you may
retrieve either the actual data type, or `Nothing'. That
"a" represents an item of the actual type. The complete
type of the list would be `option ModuleType'.

However it's done, obviously the fun is in the way a program
can use typed expressions. Given a classic Python idiom, where
the programmer has learned that optmodlist may contain Nones,

v = optmodlist
if v is None:
print i, '(None)'
else:
print i, 'Module', v.__name__

A strongly typed language will do just the same thing, but in a
more explicit and rigorous way, under the sanction of the compiler.
Like

case optmodlist:
of Nothing:
print i, '(None)'
of Some v:
print i, v.__name__

One of the problems though is how we fit Python's OOP model in here.
List types like `option ModuleType' seem to be restricted to subtype
polymorphism, plus casting to subtypes, which is no fun. We would
surely not chafe at an `option FileType' that doesn't allow StringIO.
So maybe the whole system needs to come from a really different angle,
possibly having nothing to do with implementation types like FileType,
NoneType, classes, but instead maybe the interface ideas that have
been going around for some time now. And of course one could want
the contents of a list to conform to a single interface, thus being
homogeneous in yet another sense.

Donn Cave, (e-mail address removed)

 

[Arthur]

| Yet you insist, with a fresh start on all this, on using the
| terminology "homogenous data".

Oh, well. You knew what he meant, though, didn't you?

Not really. In fact to someone like myself who has a decent practical
and intuitive sense of the use of lists in Python, the employment of
this terminology seems almost like purposeful mystification.

If he simply said "list" I would know what he was talking about.

Better.

And that was just as true when this thread started.

As interesting - in some sense - as the discussion has been, and as
wrapped up in it as I got, I realize I haven't learned anything
actually useful.

Did I take a detour.

This is my impression more of how Lisp people like to spend their time


Art

 

[Arthur]

Note that
the passage above describes a slightly different homogeneity.

Why if Martin was consciously using the terminolgy differently than it
had been used before - which is one of the possbilities I had
identified - would he choose not to disclose the fact. If some kind of
purposeful mystification was not at least an unconscious motivation.

This list still contains a module and a None, but now some
arrangement has been made to give them each the same type, when
before they were of completely disparate types (and still are.)
Well, I'm not really sure what he has in mind there, so there
is some ambiguity for students of homogeneity such as ourselves.

I have concluded that one needs a post-doc in ambiguity as a
prerequisite to becoming a student of homogeneity.

Art