"index" method only for mutable sequences??

[C.L.]

I was looking for a function or method that would return the index to the first
matching element in a list. Coming from a C++ STL background, I thought it might
be called "find". My first stop was the Sequence Types page of the Library
Reference (http://docs.python.org/lib/typesseq.html); it wasn't there. A search
of the Library Reference's index seemed to confirm that the function did not
exist. A little later I realized it might be called "index" instead. Voila.

My point is that the docs list and describe it as a method that only exists for
MUTABLE sequences. Why only for mutables? The class of objects I would expect it
to cover would be all ordered sequences, or, to phrase it a little more
pointedly, anything that supports ordered INDEXing. My understanding is that
dict's don't fall into that class of objects since their ordering is not
documented or to be depended on. However, tuple's do support ordered indexing,
so why don't tuple's have an index method?

P.S.: I know I haven't yet gotten an answer to my "why" question yet, but,
assuming it's just an oversight or an example of design without the big picture
in mind, an added benefit to fixing that oversight would be that the "index"
method's documentation could be moved from the currently odd seeming location on
the "Mutable Sequence Types" page to a place someone would look for it logically.

P.P.S.: As much as the elementary nature of my question would make it seem, this
isn't my first day using Python. I've used it on and off for several years and I
LOVE Python. It is only because of my love for the language that I question its
ways, so please don't be overly defensive when I guess that the cause for this
possible oversight is a lack of design.

Corey Lubin

 

[7stud]

I was looking for a function or method that would return the index to the first
matching element in a list. Coming from a C++ STL background, I thought it might
be called "find". My first stop was the Sequence Types page of the Library
Reference (http://docs.python.org/lib/typesseq.html); it wasn't there. A search
of the Library Reference's index seemed to confirm that the function did not
exist. A little later I realized it might be called "index" instead. Voila.

My point is that the docs list and describe it as a method that only exists for
MUTABLE sequences. Why only for mutables? The class of objects I would expect it
to cover would be all ordered sequences, or, to phrase it a little more
pointedly, anything that supports ordered INDEXing. My understanding is that
dict's don't fall into that class of objects since their ordering is not
documented or to be depended on. However, tuple's do support ordered indexing,
so why don't tuple's have an index method?

P.S.: I know I haven't yet gotten an answer to my "why" question yet, but,
assuming it's just an oversight or an example of design without the big picture
in mind, an added benefit to fixing that oversight would be that the "index"
method's documentation could be moved from the currently odd seeming location on
the "Mutable Sequence Types" page to a place someone would look for it logically.

P.P.S.: As much as the elementary nature of my question would make it seem, this
isn't my first day using Python. I've used it on and off for several years and I
LOVE Python. It is only because of my love for the language that I question its
ways, so please don't be overly defensive when I guess that the cause for this
possible oversight is a lack of design.

Corey Lubin

Looking around google a little bit, people have been asking that same
questions since at least 1992. Here is what the BDFL has to say:

Guido van Rossum ([email protected])
Wed, 04 Dec 91 18:48:34 +0100

In reply to: Steven D. Majewski: "Why no index for tuples or strings ?"

Most of the functions that operate on mutable sequences but NOT on
immutable ones are obviously there because they DO CHANGE the sequence.
BUT: why no string.index() or tuple.index() ?

Is this just an oversight ?
If not, what is the reason?

Umm, there isn't a real good reason. One thing I can say in my
defense is that string and tuple objects have no methods at all, all
operations on these are done with built-in operations like "+" and
"[...]", so adding an "index" method would be a bit of a change in the
structure.

For tuples, I suspect such a function would rarely be used; I think
that is most cases where x.index() would be useful, x is generally a
list, whose contents varies in time, rather than a tuple (which cannot
change easily).

For strings, there is a built-in module "string" which exports a
function "index" which searches for substrings, so you can say

string.index('one two three', 'two')

--Guido van Rossum, CWI, Amsterdam <[email protected]>

 

[James Stroud]

I was looking for a function or method that would return the index to the first
matching element in a list. Coming from a C++ STL background, I thought it might
be called "find". My first stop was the Sequence Types page of the Library
Reference (http://docs.python.org/lib/typesseq.html); it wasn't there. A search
of the Library Reference's index seemed to confirm that the function did not
exist. A little later I realized it might be called "index" instead. Voila.

My point is that the docs list and describe it as a method that only exists for
MUTABLE sequences. Why only for mutables? The class of objects I would expect it
to cover would be all ordered sequences, or, to phrase it a little more
pointedly, anything that supports ordered INDEXing. My understanding is that
dict's don't fall into that class of objects since their ordering is not
documented or to be depended on. However, tuple's do support ordered indexing,
so why don't tuple's have an index method?

P.S.: I know I haven't yet gotten an answer to my "why" question yet, but,
assuming it's just an oversight or an example of design without the big picture
in mind, an added benefit to fixing that oversight would be that the "index"
method's documentation could be moved from the currently odd seeming location on
the "Mutable Sequence Types" page to a place someone would look for it logically.

P.P.S.: As much as the elementary nature of my question would make it seem, this
isn't my first day using Python. I've used it on and off for several years and I
LOVE Python. It is only because of my love for the language that I question its
ways, so please don't be overly defensive when I guess that the cause for this
possible oversight is a lack of design.

Corey Lubin

The amount of typing wasted to defend design decisions such as this can
boggle one's mind. Just use lists unless you have on overwhelming reason
to do otherwise.

James

 

[Dennis Lee Bieber]

Looking around google a little bit, people have been asking that same
questions since at least 1992. Here is what the BDFL has to say:

Guido van Rossum ([email protected])
Wed, 04 Dec 91 18:48:34 +0100

Please note that a lot has changed in Python in 10+ years...

Umm, there isn't a real good reason. One thing I can say in my
defense is that string and tuple objects have no methods at all, all

For example, the string /module/ is now deprecated as essentially
all its functions are now methods of string objects themselves.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[C.L.]

The amount of typing wasted to defend design decisions such as this can
boggle one's mind. Just use lists unless you have on overwhelming reason
to do otherwise.

James

Read the quote. I *am* using a list.

That doesn't change the fact that this is unfriendly design. It's an ugly
inconsistent chunk of a Python's past in which built-in types didn't behave like
objects. It sticks out like a sore thumb, maybe just not very often.

Oh, and thanks for the insulting tone of your anticipated response. Have you
anything better to do with your time than wasting bytes writing empty responses
to what you already deem a waste of typing?

*sighs* just what I expected: another idle troll defending something just for
the sake of defending it. On the other hand, thanks 7stud, for the truly helpful
response.

 

[Steve Holden]

Read the quote. I *am* using a list.

That doesn't change the fact that this is unfriendly design. It's an ugly
inconsistent chunk of a Python's past in which built-in types didn't behave like
objects. It sticks out like a sore thumb, maybe just not very often.

OK, if you want a *reason*, the *reason* is that tuples were originally
intended to be used in the same way that tuples are used in mathematics:
as an ordered collection of dissimilar objects. Given that the sequence
held by a tuple wasn't intended to be homogeneous it didn't originally
make sense to be able to find something (which would of necessity be of
a particular type) in it.

Of course much has changed since then, and nowadays the world goes in
for tuple-abuse. Consequently the majority don't appear to understand
why tuple doesn't become simply an immutable list. But you have clearly
found the preferred solution on your own, so this is basically just a
history lesson.

Glad you asked? Is your thumb any less sore.

Oh, and thanks for the insulting tone of your anticipated response. Have you
anything better to do with your time than wasting bytes writing empty responses
to what you already deem a waste of typing?

I'd have thought you would have saved time simply by refusing to rise to
what you clearly see as bait.

*sighs* just what I expected: another idle troll defending something just for
the sake of defending it. On the other hand, thanks 7stud, for the truly helpful
response.

Get over it. This is Usenet, abuse is next door.

regards
Steve

 

[Paul Boddie]

That doesn't change the fact that this is unfriendly design. It's an ugly
inconsistent chunk of a Python's past in which built-in types didn't behave like
objects. It sticks out like a sore thumb, maybe just not very often.

When this topic last appeared on my radar, I ended up writing a long
message about it:

http://groups.google.com/group/comp.lang.python/msg/30e89128bdeb59c0

[...]

*sighs* just what I expected: another idle troll defending something just for
the sake of defending it. On the other hand, thanks 7stud, for the truly helpful
response.

The problem with 7stud's quote from GvR is that it's out of date:
tuples do have methods now, as you've noticed, but just not the index
method. Previously, I've missed that method, and it wouldn't be hard
to add it to the tuple class (in CPython's own source code), but one
has to wonder whether it's really necessary, or at least as necessary
as for other classes. Certainly, there's a trade-off between essential
functionality and having, say, 100 methods which are all useful to
someone but which make interactive introspection a rather tedious and
confusing business.

Paul

 

[7stud]

The problem with 7stud's quote from GvR is that it's out of date:

I would argue that it shows the very guy who invented the language
stated publicly there was no good reason for tuples not to have an
index method---except for consistency; tuples had no other methods.
Now that tuples have other methods, the only justification he stated
no longer exists.

 

[James Stroud]

Read the quote. I *am* using a list.

That doesn't change the fact that this is unfriendly design. It's an ugly
inconsistent chunk of a Python's past in which built-in types didn't behave like
objects. It sticks out like a sore thumb, maybe just not very often.

Oh, and thanks for the insulting tone of your anticipated response. Have you
anything better to do with your time than wasting bytes writing empty responses
to what you already deem a waste of typing?

*sighs* just what I expected: another idle troll defending something just for
the sake of defending it. On the other hand, thanks 7stud, for the truly helpful
response.

I think you misinterpreted my post, I agree with you. Please read it
again. You have touched on a very old topic. Many people have fought
tooth and nail to defend arbitrary design decisions such as a tuple not
having an index. It boils down to the fact that tuples are useless as a
result unless you know you really need them--and you never really NEED them.

James

 

[Carsten Haese]

I would argue that it shows the very guy who invented the language
stated publicly there was no good reason for tuples not to have an
index method---except for consistency; tuples had no other methods.
Now that tuples have other methods, the only justification he stated
no longer exists.

Except that that wasn't the only justification. GvR also said:

"""
For tuples, I suspect such a function would rarely be used; I think
that is most cases where x.index() would be useful, x is generally a
list, whose contents varies in time, rather than a tuple (which cannot
change easily).
"""

The lack of convincing use cases is still a pertinent reason today. Note
that the original poster on this thread did not present a use case for
tuple.index, they were only asking out of curiosity.

If you have a use case for tuple.index, please show it to me, and I'll
show you what you should be using instead of a tuple.

-Carsten

 

[7stud]

Except that that wasn't the only justification. GvR also said:

"""
For tuples, I suspect such a function would rarely be used; I think
that is most cases where x.index() would be useful, x is generally a
list, whose contents varies in time, rather than a tuple (which cannot
change easily).
"""

Touche.

 

[bearophileHUGS]

Carsten Haese:

The lack of convincing use cases is still a pertinent reason today. Note
that the original poster on this thread did not present a use case for
tuple.index, they were only asking out of curiosity.
If you have a use case for tuple.index, please show it to me, and I'll
show you what you should be using instead of a tuple.

Maybe we can add such methods to the PyPy tuples for some time, to
experimentally see if they make the language worse

(Adding such methods may reduce the amound of information you have to
keep in your brain to program with Python. If tuples and lists share
more methods then you don't have to remember what methods tuples don't
have. This means less complexity.)

Bye,
bearophile

 

[Carsten Haese]

Carsten Haese:

Maybe we can add such methods to the PyPy tuples for some time, to
experimentally see if they make the language worse

Adding useless features always makes a product worse. What's your use
case for tuple.index?

-Carsten

 

[bearophileHUGS]

Carsten Haese:

Adding useless features always makes a product worse. What's your use
case for tuple.index?

Ruby is a bit younger than Python, it has shown that few things may be
better done in a different way. An advantage of PyPy is that it allows
faster and simpler ways to perform language experiments. So you can
even try things first and judge them later. You can find usercases
later. This may help rejuvenate Python a bit

Bye,
bearophile

 

[7stud]

Adding useless features always makes a product worse. What's your use
case for tuple.index?

-Carsten

I'll trade you an index method for tuples for the whole complex number
facility.

 

[Alan Isaac]

Adding useless features always makes a product worse. What's your use
case for tuple.index?

I find this question odd for the following reason:
I doubt that *anyone* who programs in Python
has not encountered the situation where they change
a tuple to a list *solely* for the purpose of getting
access to the index method. There is simply no
conflict between the index method and immutability,
but at the moment you are forced to choose.

Anyway, for a simple use case, consider a game,
where the fixed set p of players have a fixed order.
A tuple is natural. Now for a player you want to
construct the opponents. If I had the index i it wd
be p[:i]+p[i+1:], but how to get the index?

Cheers,
Alan Isaac

 

[Carsten Haese]

Adding useless features always makes a product worse. What's your use
case for tuple.index?

[...] consider a game,
where the fixed set p of players have a fixed order.
A tuple is natural. Now for a player you want to
construct the opponents. If I had the index i it wd
be p[:i]+p[i+1:], but how to get the index?

opponents = tuple(x for x in p if x is not current_player)

-Carsten

 

[Paul Boddie]

Carsten Haese:

Ruby is a bit younger than Python, it has shown that few things may be
better done in a different way.

I think the Ruby way is just to add a ton of methods to every class
and to give them all aliases as well. Then you let the programmer
"monkey patch" those classes in their own code, too.

An advantage of PyPy is that it allows faster and simpler ways to perform language experiments. So you can
even try things first and judge them later. You can find usercases later. This may help rejuvenate Python a bit

It's virtually a matter of copy and paste to do this with CPython.
Here's a patch against the SVN trunk:

http://sourceforge.net/tracker/index.php?func=detail&aid=1696444&group_id=5470&atid=305470

Paul

 

[Paul Rubin]

Adding useless features always makes a product worse. What's your use
case for tuple.index?

Do you not see the gratuituous inconsistency between tuples and lists
as a useless feature? What is the use case for keeping it?

 

[Mel Wilson]

I'll trade you an index method for tuples for the whole complex number
facility.

Actually, I've found the use cases for list.index to be kind of thin.
Long before I think "Which one of these items is a 3?", I seem to
have thought "dictionary".

Cheers, Mel.