terminological obscurity

[Michael Chermside]

All tuple methods are also list methods, and most list methods are also tuple
methods; among those that are NOT also tuple methods, there are exactly two
('count' and 'index') that do not involve mutation. Is there any special reason
why they AREN'T also tuple methods?

Yes. Both make sense only if you consider a tuple as a homogeneous
sequence of items, and that's not what Guido intended it to be
used for.

A question about terminology ('namespace'):

prince=tuple()
king=[prince]
del prince

At this point, does the object formerly known as prince belong to the
namespace implemented by globals()? More generally, is there a
terminological way to distinguish between (1) a function from a set
of names into a set of objects, and (2) the aforementioned set of
objects?

After executing your code, there exist two objects, one is a tuple
and the other is a list. The global namespace contains one binding:
the name "king" is bound to the aforementioned list. The tuple is
not referred to directly by any name in the global namespace but it
will not be garbage collected yet because it is referenced by the
list and cannot be freed until the list itself is freed.

Whether this answers your questions I'm not sure... the questions
didn't make sense to me.

Is there a handy noun that refers to sameness of identity in the same
way that 'equality' refers to sameness of value? ('Identicalness' is
pretty clumsy, and 'identity' is confusing, since it already has a
meaning that is closely related but needs to be kept distinct.)

I've usually heard "identity" used. I don't know of any other synonynms
to use here.

Suppose X is a container that contains n items (incidentally, is 'items'
the right term?) and i in an integer with 0<=i<=n. Does " X " count
as a 'name'?

"items" is a perfectly good term for the things in a list. In common
usage, "X" is not a name. It is, however, an "L-value" -- a slightly
related term which (unlike "name") has a fairly precise definition.

-- Michael Chermside

 

[Grant Edwards]

Yes. Both make sense only if you consider a tuple as a homogeneous
sequence of items, and that's not what Guido intended it to be
used for.

I'm sure I'm being dim, but I don't understand what homogeneity
has to do with it.

For example, why shouldn't index() find an object in a
non-homogeneous sequence? Either the object is in the sequence or
it's not. If it is, there is an index that corresponds to it.

The relationship

(a,b,c,d,e)[3] is d

is true regardless of the types of a,b,c and e.

I can maybe see why not supporting sort() or reduce() on a
non-homogeneous sequence makes sense if one was of the opinion
that it should be illegal to use a binary operator on two
objects whose types differ, but I don't see why either count()
or index() should have anything to do with homogeneity, since
it pretty much has to be OK to use "is" or "==" on objects of
differing types.

 

[Elaine Jackson]

| Elaine Jackson writes:
| > All tuple methods are also list methods, and most list methods are also
tuple
| > methods; among those that are NOT also tuple methods, there are exactly two
| > ('count' and 'index') that do not involve mutation. Is there any special
| reason
| > why they AREN'T also tuple methods?
|
| Yes. Both make sense only if you consider a tuple as a homogeneous
| sequence of items, and that's not what Guido intended it to be
| used for.

####################################################
This invites the question: What DID he intend it to be used for?
Also, like the other respondent, I don't understand what homogeneity has to do
with it.
####################################################

|
| > A question about terminology ('namespace'):
| >
| > >>> prince=tuple()
| > >>> king=[prince]
| > >>> del prince
| >
| > At this point, does the object formerly known as prince belong to the
| > namespace implemented by globals()? More generally, is there a
| > terminological way to distinguish between (1) a function from a set
| > of names into a set of objects, and (2) the aforementioned set of
| > objects?
|
| After executing your code, there exist two objects, one is a tuple
| and the other is a list. The global namespace contains one binding:
| the name "king" is bound to the aforementioned list. The tuple is
| not referred to directly by any name in the global namespace but it
| will not be garbage collected yet because it is referenced by the
| list and cannot be freed until the list itself is freed.
|
| Whether this answers your questions I'm not sure... the questions
| didn't make sense to me.

#############################################################
I'm trying to find out (for a start) whether the term 'global namespace' refers
to (1) the set of bindings, or (2) the set of bindings, together with any
objects that currently exist but do not have "real" names.
#############################################################

|
| > Is there a handy noun that refers to sameness of identity in the same
| > way that 'equality' refers to sameness of value? ('Identicalness' is
| > pretty clumsy, and 'identity' is confusing, since it already has a
| > meaning that is closely related but needs to be kept distinct.)
|
| I've usually heard "identity" used. I don't know of any other synonynms
| to use here.
|
| > Suppose X is a container that contains n items (incidentally, is 'items'
| > the right term?) and i in an integer with 0<=i<=n. Does " X " count
| > as a 'name'?
|
| "items" is a perfectly good term for the things in a list. In common
| usage, "X" is not a name. It is, however, an "L-value" -- a slightly
| related term which (unlike "name") has a fairly precise definition.

#############################################################
Do you know a good place to find a discussion of matters like this?
BTW, thanks for responding.
Peace
#############################################################

 

[Shalabh Chaturvedi]

Yes. Both make sense only if you consider a tuple as a homogeneous
sequence of items, and that's not what Guido intended it to be
used for.

I'm sure I'm being dim, but I don't understand what homogeneity
has to do with it.

For example, why shouldn't index() find an object in a
non-homogeneous sequence? Either the object is in the sequence or
it's not. If it is, there is an index that corresponds to it.

The relationship

(a,b,c,d,e)[3] is d

is true regardless of the types of a,b,c and e.

I can maybe see why not supporting sort() or reduce() on a
non-homogeneous sequence makes sense if one was of the opinion
that it should be illegal to use a binary operator on two
objects whose types differ, but I don't see why either count()
or index() should have anything to do with homogeneity, since
it pretty much has to be OK to use "is" or "==" on objects of
differing types.

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

This might be the reason there is no index() on tuples - no convincing use
case.

 

[Donn Cave]

I'm sure I'm being dim, but I don't understand what homogeneity
has to do with it.

For example, why shouldn't index() find an object in a
non-homogeneous sequence? Either the object is in the sequence or
it's not. If it is, there is an index that corresponds to it.

For example,
tm = time.localtime(time.time())
i = tm.index(5)

What would that mean?

It's absurd to search for the location of a value in a tuple,
because the values don't have any meaning independent of their
location.

That sort of is a homogeneity issue, but it's confusing because
here we don't mean each element is similar to the others - in
fact that does often hold for tuples - but rather that the sequence
itself is similar from one place to another. Which is true for
lists - normally there's no real meaning attached to location -
but not for tuples, where normally location determines meaning.

Donn Cave, (e-mail address removed)

 

[John Roth]

| Elaine Jackson writes:
| > All tuple methods are also list methods, and most list methods are also
tuple
| > methods; among those that are NOT also tuple methods, there are exactly two
| > ('count' and 'index') that do not involve mutation. Is there any special
| reason
| > why they AREN'T also tuple methods?
|
| Yes. Both make sense only if you consider a tuple as a homogeneous
| sequence of items, and that's not what Guido intended it to be
| used for.

####################################################
This invites the question: What DID he intend it to be used for?
Also, like the other respondent, I don't understand what homogeneity has to do
with it.
####################################################

This is one of the longstanding issues. Guido intended lists
for conceptually homogeneous cases: that is, part of a list
is conceptually similar to the entire list.

Tuples are intended for places where you want to simply
gather up a bunch of objects into one object for convenience
in passing them around. Assume, for example, that I've got
a tuple that includes a name, address, postal code, telephone
number, part number and order quantity. Half of that tuple
is not conceptually the same as the entire tuple. That's what
is meant by inhomogenaity.

There are a number of places where this gets sticky,
and other people regard other properties as more important.
It is, however, Guido's language. He's the Benevolant Dictator
for Life, so his intention is the official intention.

John Roth

 

[Grant Edwards]

For example,
tm = time.localtime(time.time())
i = tm.index(5)

What would that mean?

It's absurd to search for the location of a value in a tuple,
because the values don't have any meaning independent of their
location.

OK, I see what you mean. That brings up the question of why
use integer indexes to access members of of a group of objects
when the order of the objects is meaningless?

 

[Terry Reedy]

This is one of the longstanding issues. Guido intended lists
for conceptually homogeneous cases: that is, part of a list
is conceptually similar to the entire list.

Tuples are intended for places where you want to simply
gather up a bunch of objects into one object for convenience
in passing them around. Assume, for example, that I've got
a tuple that includes a name, address, postal code, telephone
number, part number and order quantity. Half of that tuple
is not conceptually the same as the entire tuple. That's what
is meant by inhomogenaity.

The argument against tuple.count() and tuple.index() could also be used
against tuple slicing, but I won't say that too loudly.

There are a number of places where this gets sticky,
and other people regard other properties as more important.

For me, mutability is pragmatically the most important. I would prefer
that .count, .index, and .rindex were identical across sequences.

It is, however, Guido's language. He's the Benevolant Dictator
for Life, so his intention is the official intention.

But anyone is free to implement private intentions with count and index
functions. The itertools make it easy to write efficient and more general
functions which count or locate items produced by *any* iterable, not just
lists, that match any criterion, not just equality to a particular value.
So the addition of two specialized methods to one type is not currently an
issue to me.

Terry J. Reedy

 

[Aahz]

OK, I see what you mean. That brings up the question of why
use integer indexes to access members of of a group of objects
when the order of the objects is meaningless?

Because it's lightweight compared to using string indexes (i.e. a dict).

 

[Donn Cave]

OK, I see what you mean. That brings up the question of why
use integer indexes to access members of of a group of objects
when the order of the objects is meaningless?

I would somewhat strictly speaking say, sure, order is
not ordinarily applicable to tuples, but only in the sense
that it describes a _relative_ position, as in "after" or
"before". That's the way lists work, not tuples.

But of course absolute position is vitally important in a
tuple, as actually implemented in Python. I am guessing
that your question is basically, why use a sequence at
all, and not a collection of attributes & values like a
dict or class.

If course that's done - we can and do sometimes use a
dict or class instead. But then you don't get unpacking,
like for k, v in dict.items() ... And this same pattern
occurs on other languages, notably Haskell which has all
three types - a (head:tail) list, a tuple (rarely more than
two or three long), and a struct. The tuple is usually
evaluated in a pattern match analogous to unpacking.

I think positional structure can be pretty useful, not
necessarily inferior to attributes & values in every case.
I understand that crows can count to three - if they're
watching people enter and leave from a shed, they can keep
track as long as there aren't more than three at a time.
Maybe our cognitive abilities with tuples isn't much greater,
but within those limits they work well.

Donn Cave, (e-mail address removed)

 

[Arthur]

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

"conceptual homogeneneity" defined - as far as I see it - by
reference to whether a rational Python programmer would group the
objects together in a list.

A perfect tautology.

Which always seems to me to create more confusion, than clarification.

Art

 

[John Roth]

OK, I see what you mean. That brings up the question of why
use integer indexes to access members of of a group of objects
when the order of the objects is meaningless?

As Ahaz said, because it's lightweight. That's got its benefits
and its drawbacks. In one sense a tuple is a lightweight version
of a Data Object, but it doesn't segue into one cleanly. See the
gyrations that they had to go through to slide a data object in
under the time and stat tuples in release 2.2 (which is something
I heartily approve of - now we need to add a few methods to
those objects...)

John Roth

 

[Arthur]

"conceptual homogeneneity" defined - as far as I see it - by
reference to whether a rational Python programmer would group the
objects together in a list.

A perfect tautology.

Which always seems to me to create more confusion, than clarification.

Further to what bothers me here:

Can't it be said, in helping to distinguish a Python list from the
standard collections in, say, Java and C++ - that among its most
important attributes is the ease with which one can work with a list
as a collection of objects of *heterogenous* type. "Type" here being
used in the sense that programmers generally use the word.

In exploring Python early on, I found this to be a core feature, and a
real attraction.

Am I missing something again?

Art

 

[Grant Edwards]

Further to what bothers me here:

Can't it be said, in helping to distinguish a Python list from the
standard collections in, say, Java and C++ - that among its most
important attributes is the ease with which one can work with a list
as a collection of objects of *heterogenous* type. "Type" here being
used in the sense that programmers generally use the word.

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.

In exploring Python early on, I found this to be a core
feature, and a real attraction.

Same here.

Am I missing something again?

If so, then I guess we both are.

 

[Donn Cave]

Quoth Arthur <[email protected]>:
....
| Can't it be said, in helping to distinguish a Python list from the
| standard collections in, say, Java and C++ - that among its most
| important attributes is the ease with which one can work with a list
| as a collection of objects of *heterogenous* type. "Type" here being
| used in the sense that programmers generally use the word.
|
| In exploring Python early on, I found this to be a core feature, and a
| real attraction.
|
| Am I missing something again?

I think so, but if it's that you're actually missing the dozen or
so posts on this topic today, perhaps you can find them on Google.
Otherwise, don't know what to say.

Donn

 

[David Eppstein]

Can't it be said, in helping to distinguish a Python list from the
standard collections in, say, Java and C++ - that among its most
important attributes is the ease with which one can work with a list
as a collection of objects of *heterogenous* type. "Type" here being
used in the sense that programmers generally use the word.

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.[/QUOTE]

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.

 

[Dan Bishop]

OK, I see what you mean. That brings up the question of why
use integer indexes to access members of a group of objects
when the order of the objects is meaningless?

The order of a list can be meaningful. For example, you might want to
arrange items in chronological order, or alphabetical order. What do
you think .sort() is for?

The difference is that for tuples, the ordering affects the entire
meaning of the data. As I'm writing this, the date/time tuple for the
current local time starts with (2004, 5, 21, 23, 59, 4). This is not
conceptually equivalent to the rearrangement of (2004, 4, 5, 21, 23,
59), because it represents a different date and time.

 

[Michael Geary]

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.

Of course, if you do have an application where it's useful to use a list of
heterogeneous types for heterogeneous purposes, no harm whatsoever will come
of it.

Guido may wish you didn't do that, but I have a feeling he's busy with other
things and isn't really that concerned about it. Besides, you don't have to
tell him.

-Mike

 

[Donn Cave]

Quoth Grant Edwards <[email protected]>:
....
| 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'll have to either try to understand what people mean, or ignore
them. Either will work better than the above. A heterogeneous
sequence can mean at least two things, not because there's anything
ambiguous about "heterogeneous" on its own, but because of the way
it's applied to the sequence. The notion that this is a distinctive
difference between lists and tuples is ridiculous if you take one
of those meanings, sensible if you take the other. Your choice.

....
|> Am I missing something again?
|
| If so, then I guess we both are.

It's lucky you two have found each other.

Donn

 

[Arthur]

Quoth Grant Edwards <[email protected]>:
...
| 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'll have to either try to understand what people mean, or ignore
them. Either will work better than the above. A heterogeneous
sequence can mean at least two things, not because there's anything
ambiguous about "heterogeneous" on its own, but because of the way
it's applied to the sequence. The notion that this is a distinctive
difference between lists and tuples is ridiculous if you take one
of those meanings, sensible if you take the other. Your choice.

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.

Art