"index" method only for mutable sequences??

12 views
Skip to first unread message

C.L.

unread,
Apr 5, 2007, 10:46:00 PM4/5/07
to pytho...@python.org
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

unread,
Apr 5, 2007, 11:20:27 PM4/5/07
to

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 (Guido.va...@cwi.nl)
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 <gu...@cwi.nl>

James Stroud

unread,
Apr 6, 2007, 1:03:16 AM4/6/07
to

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

Message has been deleted

C.L.

unread,
Apr 6, 2007, 2:46:57 AM4/6/07
to pytho...@python.org
James Stroud <jstroud <at> mbi.ucla.edu> writes:
>
> C.L. wrote:
> > I was looking for a function or method that would return the index to the
> > first matching element in a list. ...
> > ... __please don't be overly defensive__ ...

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

unread,
Apr 6, 2007, 7:39:35 AM4/6/07
to pytho...@python.org
C.L. wrote:
> James Stroud <jstroud <at> mbi.ucla.edu> writes:
>> C.L. wrote:
>>> I was looking for a function or method that would return the index to the
>>> first matching element in a list. ...
>>> ... __please don't be overly defensive__ ...
>> 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.
>
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

Paul Boddie

unread,
Apr 6, 2007, 9:56:11 AM4/6/07
to
C.L. wrote:
>
> 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

unread,
Apr 6, 2007, 2:33:47 PM4/6/07
to
On Apr 6, 7:56 am, "Paul Boddie" <p...@boddie.org.uk> wrote:
> 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

unread,
Apr 6, 2007, 3:05:51 PM4/6/07
to

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

unread,
Apr 6, 2007, 3:24:17 PM4/6/07
to pytho...@python.org

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

unread,
Apr 7, 2007, 6:25:05 AM4/7/07
to
On Apr 6, 1:24 pm, Carsten Haese <cars...@uniqsys.com> wrote:
> 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.


bearoph...@lycos.com

unread,
Apr 7, 2007, 9:45:20 AM4/7/07
to
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

unread,
Apr 7, 2007, 10:27:20 AM4/7/07
to pytho...@python.org
On Sat, 2007-04-07 at 06:45 -0700, bearoph...@lycos.com wrote:
> 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 useless features always makes a product worse. What's your use
case for tuple.index?

-Carsten


bearoph...@lycos.com

unread,
Apr 7, 2007, 11:49:50 AM4/7/07
to
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

unread,
Apr 7, 2007, 3:18:57 PM4/7/07
to
On Apr 7, 8:27 am, Carsten Haese <cars...@uniqsys.com> wrote:

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

Alan Isaac

unread,
Apr 7, 2007, 10:40:52 PM4/7/07
to

"Carsten Haese" <car...@uniqsys.com> wrote in message
news:mailman.6146.1175956...@python.org...

> 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

unread,
Apr 7, 2007, 11:59:48 PM4/7/07
to pytho...@python.org
On Sun, 08 Apr 2007 02:40:52 GMT, Alan Isaac wrote

> "Carsten Haese" <car...@uniqsys.com> wrote in message
> news:mailman.6146.1175956...@python.org...
> > 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

unread,
Apr 8, 2007, 10:41:20 AM4/8/07
to
bearoph...@lycos.com wrote:
> 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.

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

unread,
Apr 8, 2007, 10:51:36 AM4/8/07
to
Carsten Haese <car...@uniqsys.com> writes:
> > 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?

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

unread,
Apr 8, 2007, 11:27:24 AM4/8/07
to pytho...@python.org
7stud wrote:
> On Apr 7, 8:27 am, Carsten Haese <cars...@uniqsys.com> wrote:
>> Adding useless features always makes a product worse. What's your use
>> case for tuple.index?

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

Carsten Haese

unread,
Apr 8, 2007, 3:40:27 PM4/8/07
to pytho...@python.org

When a new feature is requested, the burden of proof is on the requester
to show that it has uses. The use case for not having tuple.index is
that there are no use cases for having it. If that answer sounds absurd,
it is because your question is absurd.

-Carsten


Paul Rubin

unread,
Apr 8, 2007, 4:10:16 PM4/8/07
to
Carsten Haese <car...@uniqsys.com> writes:
> > Do you not see the gratuituous inconsistency between tuples and lists
> > as a useless feature? What is the use case for keeping it?
>
> When a new feature is requested, the burden of proof is on the requester
> to show that it has uses. The use case for not having tuple.index is
> that there are no use cases for having it. If that answer sounds absurd,
> it is because your question is absurd.

The use case has already been discussed. Removing the pointless
inconsistency between lists and tuples means you can stop having to
remember it, so you can free up brain cells for implementing useful
things. That increases your programming productivity.

Bart Willems

unread,
Apr 8, 2007, 7:42:50 PM4/8/07
to
James Stroud wrote:
> ... 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.

Could you clarify that for me? I use tuples *a lot* and I really *NEED*
them - I'm building a lot of multi-tier reports where detail-level data
is pulled out of a dictionary based on a composed key. It is impossible
to build those dictionaries *without* using tuples.

So, I *need* those tuples, and they're far from useless to me.

For the rare, rare, rare cases where I *would* need an index function on
a tuple (I've never needed it):

class IndexTuple(tuple):
def index(n):
# your code goes here

would be sufficient, wouldn't it?

Best regards,
Bart

Carsten Haese

unread,
Apr 8, 2007, 8:10:21 PM4/8/07
to pytho...@python.org

Will tuples also get a sort method? What about append and extend? pop?
__iadd__? __delslice__?

How many brain cells are actually freed up by not having to remember
that *one* method that you'd never use doesn't exist?

-Carsten


Paul Rubin

unread,
Apr 8, 2007, 8:23:03 PM4/8/07
to
Carsten Haese <car...@uniqsys.com> writes:
> Will tuples also get a sort method? What about append and extend? pop?
> __iadd__? __delslice__?

They are immutable so they won't get .sort() etc. sorted(...) already
works on them.

> How many brain cells are actually freed up by not having to remember
> that *one* method that you'd never use doesn't exist?

I dunno but I do know that Ruby is attracting a lot of potential Python
users because it apparently has fewer of these inconsistencies. A big
web site I hang out on decided to do a software rewrite (currently using
a huge perl script) and evaluated a bunch of possible approaches. In
the final decision, Ruby/Rails won out over Python/Django.

Steven D'Aprano

unread,
Apr 8, 2007, 9:50:41 PM4/8/07
to
On Sun, 08 Apr 2007 20:10:21 -0400, Carsten Haese wrote:

> On Sun, 2007-04-08 at 13:10 -0700, Paul Rubin wrote:
>> Carsten Haese <car...@uniqsys.com> writes:
>> > > Do you not see the gratuituous inconsistency between tuples and lists
>> > > as a useless feature? What is the use case for keeping it?
>> >
>> > When a new feature is requested, the burden of proof is on the requester
>> > to show that it has uses. The use case for not having tuple.index is
>> > that there are no use cases for having it. If that answer sounds absurd,
>> > it is because your question is absurd.
>>
>> The use case has already been discussed. Removing the pointless
>> inconsistency between lists and tuples means you can stop having to
>> remember it, so you can free up brain cells for implementing useful
>> things. That increases your programming productivity.
>
> Will tuples also get a sort method? What about append and extend? pop?
> __iadd__? __delslice__?

Since tuples are immutable, no.

And before you ask, since they aren't strings, they won't get upper,
lower, split or strip either.


> How many brain cells are actually freed up by not having to remember
> that *one* method that you'd never use doesn't exist?

74,972,561.


I think the problem is that Python developers are split between those who
see tuples as immutable lists, and those who see them as records/structs.
Neither of them is wrong -- tuples are multi-use. Guido may or may not
have designed them to be used as structs (short and heterogeneous, as
opposed to long and homogeneous) but designers are often surprised by the
uses people find for their creations, and the designer doesn't get the
final say as to what is the "right" usage.

If you see tuples as an immutable list, having an index method is quite
useful. If you see them as structs, an index method is useless.

--
Steven.

Paul Rubin

unread,
Apr 8, 2007, 10:05:49 PM4/8/07
to
Steven D'Aprano <st...@REMOVE.THIS.cybersource.com.au> writes:
> I think the problem is that Python developers are split between those who
> see tuples as immutable lists, and those who see them as records/structs.

I think the construction

def f(*a): ...

shows that the "immutable list" interpretation is firmly ensconced in
the language.

James Stroud

unread,
Apr 8, 2007, 10:26:37 PM4/8/07
to
Bart Willems wrote:
> James Stroud wrote:
>> ... 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.
>
> Could you clarify that for me? I use tuples *a lot* and I really *NEED*
> them - I'm building a lot of multi-tier reports where detail-level data
> is pulled out of a dictionary based on a composed key. It is impossible
> to build those dictionaries *without* using tuples.


"Impossible" is a strong word, as is "need" (especially when in all caps).

py> import md5
py> class HashedList(list):
... def __hash__(self):
... h = md5.new()
... for item in self:
... h.update(str(hash(item)))
... return int(h.hexdigest(), 16)
...
py> hl = HashedList('bob', 'carol', 'ted')
py> {hl:3}
{['bob', 'carol', 'ted']: 3}

Impossible? I wouldn't even say that this was all that difficult.

James

Steven D'Aprano

unread,
Apr 8, 2007, 11:30:29 PM4/8/07
to

Possible, if by possible you mean "broken".


>>> D = {hl: 3}
>>> D


{['bob', 'carol', 'ted']: 3}

>>> hl[0] = 'Bob'
>>> D
{['Bob', 'carol', 'ted']: 3}
>>> D.keys()[0] is hl
True
>>> D[hl]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: ['Bob', 'carol', 'ted']


--
Steven.

James Stroud

unread,
Apr 9, 2007, 1:20:45 AM4/9/07
to

def __setitem__(self, *args):
raise TypeError, '%s doesn't support item assignment.' %
self.__class__.__name__


Problem fixed. Next?

By the way, this would be analagous to the tedious

class Something(object):
def __init__(self, value):
self._value = value
value = property(lambda: self._value)

just to make sure users don't change the value of value so they don't
"break" the instance.

I don't think Bart is changing the items in his keys anyway--so the
problem which was stated as impossible is still possible. The solution
was not to code to your personal expectations but to show how tuples are
never essential. Any number of solutions could fix the problem you have
invented.

James

Georg Brandl

unread,
Apr 9, 2007, 3:41:48 AM4/9/07
to pytho...@python.org
Paul Rubin schrieb:

> Carsten Haese <car...@uniqsys.com> writes:
>> Will tuples also get a sort method? What about append and extend? pop?
>> __iadd__? __delslice__?
>
> They are immutable so they won't get .sort() etc. sorted(...) already
> works on them.
>
>> How many brain cells are actually freed up by not having to remember
>> that *one* method that you'd never use doesn't exist?
>
> I dunno but I do know that Ruby is attracting a lot of potential Python
> users because it apparently has fewer of these inconsistencies.

It remains to be proven that it is an inconsistency, rather than a design
decision.

> A big
> web site I hang out on decided to do a software rewrite (currently using
> a huge perl script) and evaluated a bunch of possible approaches. In
> the final decision, Ruby/Rails won out over Python/Django.

Given that so many web sites still decide to (re)write in PHP, I don't think
that is much of an argument.

Georg

Georg Brandl

unread,
Apr 9, 2007, 3:43:12 AM4/9/07
to pytho...@python.org
Paul Rubin schrieb:

IIRC, for this use case of tuples there was a practical reason rather than
an interpretation one. It is also on the list of potential changes for
Python 3000.

Georg

Steven D'Aprano

unread,
Apr 9, 2007, 9:03:06 AM4/9/07
to

hl.reverse()
hl.sort() # if the list isn't already sorted
del hl[0]
hl.append()
etc.


Yes, you can block those as well... but by the time you've finished making
your HashedList immutable, it is just a slower tuple with a different
name.

In other words... you can avoid using tuples by using a tuple with a
different name. You might as well just do this:

HashedList = tuple

--
Steven.

Carsten Haese

unread,
Apr 9, 2007, 9:08:26 AM4/9/07
to pytho...@python.org
On Mon, 2007-04-09 at 11:50 +1000, Steven D'Aprano wrote:
> On Sun, 08 Apr 2007 20:10:21 -0400, Carsten Haese wrote:
> > Will tuples also get a sort method? What about append and extend? pop?
> > __iadd__? __delslice__?
>
> Since tuples are immutable, no.
> [...]

>
> If you see tuples as an immutable list, having an index method is quite
> useful. If you see them as structs, an index method is useless.

Let's recall what GvR 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).
"""

In Guido's opinion, it's not the "structness" of tuples that negates the
need for tuple.index, it's their inability to be mutated easily. So
Guido seems to disagree with your notion that an index method is quite
useful for immutable lists.

I won't presume to speak for Guido, but if I had to connect the dots
between "tuples are immutable" and "tuples will rarely need an index
method", I'd do it like this: Consider an object X and a tuple T. Tuples
have "X in T" tests, so you can check if there exists some N such that
T[N]==X. The lack of the index method means you won't know the value of
N, but what would knowing N give you? You can't modify T, so all you can
do is read T[N], but you already know that that's going to return X, so
you might as well just use X.

Any use case for actually having to know N would have to involve an
operation where you end up explicitly using an index other than N, such
as slicing T from 0 to N-1, or looking at T[2*N] or something like that.
Of course such operations might be useful, but algorithms that need an
operation like that would self-document their design more clearly by
using a list instead of a tuple.

I hope this explains at least to some people how this seemingly
gratuitous inconsistency can actually be viewed as a justified design
decision.

-Carsten


OKB (not okblacke)

unread,
Apr 9, 2007, 2:01:44 PM4/9/07
to
Carsten Haese wrote:

> I won't presume to speak for Guido, but if I had to connect the
> dots between "tuples are immutable" and "tuples will rarely need an
> index method", I'd do it like this: Consider an object X and a
> tuple T. Tuples have "X in T" tests, so you can check if there
> exists some N such that T[N]==X. The lack of the index method means
> you won't know the value of N, but what would knowing N give you?
> You can't modify T, so all you can do is read T[N], but you already
> know that that's going to return X, so you might as well just use
> X.
>
> Any use case for actually having to know N would have to involve an
> operation where you end up explicitly using an index other than N,
> such as slicing T from 0 to N-1, or looking at T[2*N] or something
> like that. Of course such operations might be useful, but
> algorithms that need an operation like that would self-document
> their design more clearly by using a list instead of a tuple.

This is a reasonable argument, but all such arguments miss what I
think is an important use case for tuples: you want a list, but you need
to use it as a dictionary key.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

James Stroud

unread,
Apr 10, 2007, 12:04:17 AM4/10/07
to Steven D'Aprano

To prevent abuse.

but by the time you've finished making
> your HashedList immutable, it is just a slower tuple with a different
> name.

But has an index() method.

> In other words... you can avoid using tuples by using a tuple with a
> different name. You might as well just do this:
>
> HashedList = tuple

You can avoid using tuples any number of ways. For example, you can
catenate strings.

You seem to be under the misapprehension that I authored the Subjet
line. Please read the original quote:

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

Bear in mind that this was also a response to someone admittedly less
familiar to the language--to encourage him to use lists in favor of
tuples to avoid inconveniences later.

The HashedList is to show that you can always get around the requirement
for a tuple and thus an absolute need for a tuple doesn't exist, as
implied by the quote. I make no assertions as to the HashedLists
efficiency. I use tuples all of the time, but I could just as well
catenate strings etc. They are a language convenience that are
ultimately dispensible.

James

Antoon Pardon

unread,
Apr 10, 2007, 3:31:13 AM4/10/07
to
On 2007-04-06, Carsten Haese <car...@uniqsys.com> wrote:
> On Fri, 2007-04-06 at 11:33 -0700, 7stud wrote:
>> On Apr 6, 7:56 am, "Paul Boddie" <p...@boddie.org.uk> wrote:
>> > 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.

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

No wonder no convincing use cases for tuples have shown up. You just
defined use cases of tuples as unconvincing.

My personal opinion is that lack of use cases are used too much as an
excuse. Limiting the development of your language to use cases makes
your language less consistent and so makes your language less easy to
learn.

Of course it also limits the language to what the developers can think off.
I once thought it would be usefull to have something like a slice but
with extended functionality. So I first tried this:

class Islice(slice):
...

and I got:

type 'slice' is not an acceptable base type


then I just tried:

class Islice:
...

But an instance of such a class can't be used as an index, despited the
propoganda that is made for duck typing in this news group.

I guess the developers just couldn't see the use case of this.

But you do have to wonder when the developers started to unify classes
and types, why they just didn't go the whole wayr?. Making all types
subclassable, means you have only one case to code and the user doesn't
has to wonder whether a particular type is subclassable or not. I think
that is a bigger gain, than the potential loss one may experience
because some type that now are subclassable will never actually be
subclassed.

--
Antoon Pardon

Antoon Pardon

unread,
Apr 10, 2007, 3:45:05 AM4/10/07
to
On 2007-04-08, Carsten Haese <car...@uniqsys.com> wrote:
> On Sun, 2007-04-08 at 07:51 -0700, Paul Rubin wrote:
>> Carsten Haese <car...@uniqsys.com> writes:
>> > > 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?
>>
>> Do you not see the gratuituous inconsistency between tuples and lists
>> as a useless feature? What is the use case for keeping it?
>
> When a new feature is requested, the burden of proof is on the requester
> to show that it has uses.

I don't agree. Good or bad design is not dependant on what is
implemented and what is not.

> The use case for not having tuple.index is
> that there are no use cases for having it. If that answer sounds absurd,
> it is because your question is absurd.

You mean that those who are against tuple.index won't find any use case
convincing enough.

--
Antoon Pardon

Antoon Pardon

unread,
Apr 10, 2007, 3:42:19 AM4/10/07
to
On 2007-04-09, Georg Brandl <g.br...@gmx.net> wrote:
> Paul Rubin schrieb:
>> Carsten Haese <car...@uniqsys.com> writes:
>>> Will tuples also get a sort method? What about append and extend? pop?
>>> __iadd__? __delslice__?
>>
>> They are immutable so they won't get .sort() etc. sorted(...) already
>> works on them.
>>
>>> How many brain cells are actually freed up by not having to remember
>>> that *one* method that you'd never use doesn't exist?
>>
>> I dunno but I do know that Ruby is attracting a lot of potential Python
>> users because it apparently has fewer of these inconsistencies.
>
> It remains to be proven that it is an inconsistency, rather than a design
> decision.

The two don't contradict. A design decision can introduce an
inconsistency. AFAICS having an index method on tuples seems
rather natural. Looking for the index of a particular item in
your sequence seems just as usefull independant of the nature
of your sequence. So unless there is some rather forcefull
argument it seems inconsistent to have some sequences lacking
this method.

--
Antoon Pardon

Duncan Booth

unread,
Apr 10, 2007, 4:50:28 AM4/10/07
to
Antoon Pardon <apa...@forel.vub.ac.be> wrote:

>> When a new feature is requested, the burden of proof is on the requester
>> to show that it has uses.
>
> I don't agree. Good or bad design is not dependant on what is
> implemented and what is not.

There is a cost to every new language feature: it has to be implemented,
documented, maintained, and above all learned by the users. Good design
involves, in part, not adding to these burdens except where there is a
benefit at least equal to the cost.

>> The use case for not having tuple.index is
>> that there are no use cases for having it. If that answer sounds absurd,
>> it is because your question is absurd.
>
> You mean that those who are against tuple.index won't find any use case
> convincing enough.
>

Why not try them? Pose a few useful cases where the existence of
tuple.index() would actually give a benefit and see what response you get.

You would have to meet a few obvious conditions: the use case would need to
be one where a tuple was preferable to a list (the obvious one being where
you need to hash it), the tuple would have to be sufficiently long or the
calls to 'index' sufficiently frequent to make casting to a list so you can
call 'list(obj).index(...)' unattractive, and you actually need a reason to
be using 'index' rather than just the 'in' operator.

Antoon Pardon

unread,
Apr 10, 2007, 5:48:41 AM4/10/07
to
On 2007-04-10, Duncan Booth <duncan...@invalid.invalid> wrote:
> Antoon Pardon <apa...@forel.vub.ac.be> wrote:
>
>>> When a new feature is requested, the burden of proof is on the requester
>>> to show that it has uses.
>>
>> I don't agree. Good or bad design is not dependant on what is
>> implemented and what is not.
>
> There is a cost to every new language feature: it has to be implemented,
> documented, maintained, and above all learned by the users. Good design
> involves, in part, not adding to these burdens except where there is a
> benefit at least equal to the cost.

So what is the easiest to learn: "All sequences have an index method" or
"Such and so sequences have an index method and others don't"

Which of the above is the easiest to document?

Now with implementation and maintaining. If you would start with a class
of sequence which classes like tuple and list would inherit from, then
there also would be a single function to be implemented and maintained.
It would just be usable in more types.

>>> The use case for not having tuple.index is
>>> that there are no use cases for having it. If that answer sounds absurd,
>>> it is because your question is absurd.
>>
>> You mean that those who are against tuple.index won't find any use case
>> convincing enough.
>>
> Why not try them? Pose a few useful cases where the existence of
> tuple.index() would actually give a benefit and see what response you get.
>
> You would have to meet a few obvious conditions: the use case would need to
> be one where a tuple was preferable to a list (the obvious one being where
> you need to hash it), the tuple would have to be sufficiently long or the
> calls to 'index' sufficiently frequent to make casting to a list so you can
> call 'list(obj).index(...)' unattractive, and you actually need a reason to
> be using 'index' rather than just the 'in' operator.

If someone states: "Show me your use case for using tuple.index and I
will show you how to avoid it." or words to that effect I think there
is little use trying.

Besides I have seen how such things evolve here before. Every use case
that will be presented, will be rewritten in a way that doesn't need
tuple.index and these rewritals will be used as an argument for not
having tuple.index. If you need to hash it, you can simply subclass
list and provide a hash with your class or you can simply use tuples
and write an index function yourself.

The same happened with the ternary operator. Every use case someone
could come up with was rejected by rewriting the code without using
a ternary operator. AFAICS the only reason the ternary operator
finaly got introduced was because a python developer was bitten by an
illusive bug, introduced by one of the idioms that was often used as a
way to simulate a ternary operator.

--
Antoon Pardon

Paul Boddie

unread,
Apr 10, 2007, 6:19:21 AM4/10/07
to
On 10 Apr, 11:48, Antoon Pardon <apar...@forel.vub.ac.be> wrote:

> On 2007-04-10, Duncan Booth <duncan.bo...@invalid.invalid> wrote:
>
> > There is a cost to every new language feature: it has to be implemented,
> > documented, maintained, and above all learned by the users. Good design
> > involves, in part, not adding to these burdens except where there is a
> > benefit at least equal to the cost.
>
> So what is the easiest to learn: "All sequences have an index method" or
> "Such and so sequences have an index method and others don't"

I think this observation leads to insights both at the end-user level
and at the implementer level. Tuples and lists are sequences; the
index method can be defined generically for all sequences; adding such
a method to the tuple type can be done with barely any changes to the
implementation taken from the list type. This leads to the observation
that a generic index method (defined as a function in the
implementation) could be made to work with both lists and tuples, and
that various other methods might also be defined similarly, although
things like append, extend and other mutating methods wouldn't be
appropriate for a tuple.

> Which of the above is the easiest to document?
>
> Now with implementation and maintaining. If you would start with a class
> of sequence which classes like tuple and list would inherit from, then
> there also would be a single function to be implemented and maintained.
> It would just be usable in more types.

There isn't a "big win" in this case: the intersection of useful
methods between mutable and immutable sequence types is rather small.
Nevertheless, providing a slightly deeper abstract class hierarchy
might be appropriate, and this is being considered for Python 3000.

[...]

> The same happened with the ternary operator. Every use case someone
> could come up with was rejected by rewriting the code without using
> a ternary operator. AFAICS the only reason the ternary operator
> finaly got introduced was because a python developer was bitten by an
> illusive bug, introduced by one of the idioms that was often used as a
> way to simulate a ternary operator.

The ternary operator, whilst providing new and occasionally useful
functionality, is rather "badly phrased" in my opinion: when used,
it's a bit like reading one natural language and suddenly having the
grammar of another in use for the rest of the sentence.

Paul

Antoon Pardon

unread,
Apr 10, 2007, 6:39:00 AM4/10/07
to
On 2007-04-10, Paul Boddie <pa...@boddie.org.uk> wrote:

>> Now with implementation and maintaining. If you would start with a class
>> of sequence which classes like tuple and list would inherit from, then
>> there also would be a single function to be implemented and maintained.
>> It would just be usable in more types.
>
> There isn't a "big win" in this case: the intersection of useful
> methods between mutable and immutable sequence types is rather small.
> Nevertheless, providing a slightly deeper abstract class hierarchy
> might be appropriate, and this is being considered for Python 3000.

Well I wasn't trying to show this aspect as a big win. Just illustrating
it doesn't have to be a big cost in this case.

>> The same happened with the ternary operator. Every use case someone
>> could come up with was rejected by rewriting the code without using
>> a ternary operator. AFAICS the only reason the ternary operator
>> finaly got introduced was because a python developer was bitten by an
>> illusive bug, introduced by one of the idioms that was often used as a
>> way to simulate a ternary operator.
>
> The ternary operator, whilst providing new and occasionally useful
> functionality, is rather "badly phrased" in my opinion: when used,
> it's a bit like reading one natural language and suddenly having the
> grammar of another in use for the rest of the sentence.

I agree. The structure of the if-expression doesn't resemble the
structure of the if-statement. I think it was a bad choice to
have the two so dissimilar.

--
Antoon Pardon

Carsten Haese

unread,
Apr 10, 2007, 7:41:09 AM4/10/07
to pytho...@python.org
On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote

> On 2007-04-06, Carsten Haese <car...@uniqsys.com> wrote:
> > 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.
>
> No wonder no convincing use cases for tuples have shown up. You just
> defined use cases of tuples as unconvincing.

It's not a definition, it's an observation. I'm simply saying that all use
cases I've seen for tuple.index could be written in a clearer fashion by using
something else. Please prove me wrong by supplying a use case of tuple.index
that can not be improved by rewriting.

Note that I have proved elsewhere on this thread that any real use case for
tuple.index will involve an operation to explicitly use an index different
from the one obtained by the call to tuple.index(). I'd like to hear your
opinion on this.

> My personal opinion is that lack of use cases are used too much as an
> excuse. Limiting the development of your language to use cases makes
> your language less consistent and so makes your language less easy to
> learn.

That is your opinion, and you are entitled to your opinion. My opinion is that
adding features that don't have any uses just weigh the language down
unnecessarily, and they distract programmers from finding the best solution to
their problem.

> Of course it also limits the language to what the developers can
> think off.

Initially, yes, but if enough use cases exist for a feature that the
developers didn't think of, it will be implemented.

-Carsten

Carsten Haese

unread,
Apr 10, 2007, 7:47:46 AM4/10/07
to pytho...@python.org
On 10 Apr 2007 09:48:41 GMT, Antoon Pardon wrote

> If someone states: "Show me your use case for using tuple.index and I
> will show you how to avoid it." or words to that effect I think there
> is little use trying.

Or maybe you just can't think of any good use cases, and that's annoying you
because it proves my point. Please, prove me wrong by showing use cases for
tuple.index that can't be rewritten.

-Carsten

Antoon Pardon

unread,
Apr 10, 2007, 8:29:11 AM4/10/07
to
On 2007-04-10, Carsten Haese <car...@uniqsys.com> wrote:
> On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote
>> On 2007-04-06, Carsten Haese <car...@uniqsys.com> wrote:
>> > 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.
>>
>> No wonder no convincing use cases for tuples have shown up. You just
>> defined use cases of tuples as unconvincing.
>
> It's not a definition, it's an observation. I'm simply saying that all use
> cases I've seen for tuple.index could be written in a clearer fashion by using
> something else. Please prove me wrong by supplying a use case of tuple.index
> that can not be improved by rewriting.

No it is a defintion because it states this can be done for every
possible case, even cases you have no idea about.

> Note that I have proved elsewhere on this thread that any real use case for
> tuple.index will involve an operation to explicitly use an index different
> from the one obtained by the call to tuple.index(). I'd like to hear your
> opinion on this.

And what relevance would such a proof have?

>> My personal opinion is that lack of use cases are used too much as an
>> excuse. Limiting the development of your language to use cases makes
>> your language less consistent and so makes your language less easy to
>> learn.
>
> That is your opinion, and you are entitled to your opinion. My opinion is that
> adding features that don't have any uses just weigh the language down
> unnecessarily, and they distract programmers from finding the best solution to
> their problem.

Adding the index method to tuples is not adding a feature. It is
removing a limitation. Writing an index function in python that
works with whatever sequence is dead easy. So if the python
core implementation only works with a specific sequence that
is putting on unnecessary limitations.

>> Of course it also limits the language to what the developers can
>> think off.
>
> Initially, yes, but if enough use cases exist for a feature that the
> developers didn't think of, it will be implemented.

Which means your language will not be that usefull for a number of
things until you have frustrated enough people.

--
Antoon Pardon

Duncan Booth

unread,
Apr 10, 2007, 8:40:30 AM4/10/07
to
Antoon Pardon <apa...@forel.vub.ac.be> wrote:

> On 2007-04-10, Duncan Booth <duncan...@invalid.invalid> wrote:
>> There is a cost to every new language feature: it has to be
>> implemented, documented, maintained, and above all learned by the
>> users. Good design involves, in part, not adding to these burdens
>> except where there is a benefit at least equal to the cost.
>
> So what is the easiest to learn: "All sequences have an index method"
> or "Such and so sequences have an index method and others don't"
>
> Which of the above is the easiest to document?

The second would be if it were true. However it would mean you would have
to add an index method to *all* sequences.

FWIW, The current documentation says that 's.index' is a method defined on
all *mutable* sequence types: almost as simple as your second wording but
unfortunately misleading since strings also have index.

> If someone states: "Show me your use case for using tuple.index and I
> will show you how to avoid it." or words to that effect I think there
> is little use trying.

I genuinely cannot think of a use case. I didn't ask you to suggest one so
I could show you how to avoid it, I asked you to suggest one so that we
could take the discussion from the purely hypothetical to a more concrete
discussion of whether it would be a worthwhile enhancement.

Fair enough though. I'll assume you cannot think of a suitable use case
either.

Carsten Haese

unread,
Apr 10, 2007, 9:16:00 AM4/10/07
to pytho...@python.org
On Tue, 2007-04-10 at 12:29 +0000, Antoon Pardon wrote:
> On 2007-04-10, Carsten Haese <car...@uniqsys.com> wrote:
> > On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote
> >> On 2007-04-06, Carsten Haese <car...@uniqsys.com> wrote:
> >> > 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.
> >>
> >> No wonder no convincing use cases for tuples have shown up. You just
> >> defined use cases of tuples as unconvincing.
> >
> > It's not a definition, it's an observation. I'm simply saying that all use
> > cases I've seen for tuple.index could be written in a clearer fashion by using
> > something else. Please prove me wrong by supplying a use case of tuple.index
> > that can not be improved by rewriting.
>
> No it is a defintion because it states this can be done for every
> possible case, even cases you have no idea about.

That would be a theorem or conjecture, not a definition. You can call it
definition or banana or screwdriver if you like, but that's not going to
disprove it.

> > Note that I have proved elsewhere on this thread that any real use case for
> > tuple.index will involve an operation to explicitly use an index different
> > from the one obtained by the call to tuple.index(). I'd like to hear your
> > opinion on this.
>
> And what relevance would such a proof have?

It proves at that every conceivable use case for tuple.index, including
the ones I am not thinking of, will never directly use the index
obtained from calling tuple.index(). Such a use case will be poorly
self-documented, and a clearer implementation can be found by avoiding
tuple.index().

I'll illustrate this on the one concrete use case that was suggested on
this thread: In a game where the sequence of players is given by the
tuple p, find the opponents of the current player.

One hypothetical solution is to find the index if the current player and
then slice and reassemble the tuple:

i = p.index(current_player)
opponents = p[:i-1] + p[i+1:]

An alternative is this:

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

You may disagree, but in my opinion, the alternative is better because
it is a more natural translation of the concept that the opponents of
the current player are all players that are not the current player.

> Adding the index method to tuples is not adding a feature. It is
> removing a limitation.

The non-existence of tuple.index is only a limitation if there is a need
for the method to exist. Please prove that this need exists.

-Carsten


Antoon Pardon

unread,
Apr 10, 2007, 9:21:03 AM4/10/07
to
On 2007-04-10, Carsten Haese <car...@uniqsys.com> wrote:

No you just have proven my point. I predicted that whatever use case
would be given, people would stand ready to rewrite is and use those
rewritals as argument againt the use case. Here you are ready to do
just that.

Since you can just write an index function that works with any sequence
or you could simply write something like list(tup).index('...'), any
code that would use tupple.index can be rewritten to do without.

But that is not such a strong argument. Should the case be reversed
and tuples have an index method and lists not, you would be able
to rewrite any code that would use list.index into code that
wouldn't. But if you are so eager to rewrite, how about the following:

I am using the struct module to get binary data from a file.
Sometimes I want to skip until I find a particular binary
number. Somewhat simplified it looks like this:


class Itemfile:
def __init__(self, fn):
self.fl = open(fn)
self.ix = 80

def nextitem(self):
if self.ix == 80:
self.buf = struct.unpack("80i", self.fl.read(320))
self.ix = 0
result = self.buf[self.ix]
self.ix += 1
return result

def skipuntil(self, val):
done = False
while not done:
try:
self.ix = self.buf.index(val, self.ix)
done = True
except ValueError:
self.ix = 0
self.buf = struct.unpack("80i", self.fl.read(320))


Now I'm sure you can rewrite this without the need of tuple.index.
It just seems odd that I have to go through extra hoops here to
get the effect of tuple.index because struct.unpack returns its result
in a tuple and a tuple doesn't provide index.

--
Antoon Pardon

Antoon Pardon

unread,
Apr 10, 2007, 9:25:21 AM4/10/07
to
On 2007-04-10, Duncan Booth <duncan...@invalid.invalid> wrote:
> Antoon Pardon <apa...@forel.vub.ac.be> wrote:
>
>> On 2007-04-10, Duncan Booth <duncan...@invalid.invalid> wrote:
>>> There is a cost to every new language feature: it has to be
>>> implemented, documented, maintained, and above all learned by the
>>> users. Good design involves, in part, not adding to these burdens
>>> except where there is a benefit at least equal to the cost.
>>
>> So what is the easiest to learn: "All sequences have an index method"
>> or "Such and so sequences have an index method and others don't"
>>
>> Which of the above is the easiest to document?
>
> The second would be if it were true. However it would mean you would have
> to add an index method to *all* sequences.
>
> FWIW, The current documentation says that 's.index' is a method defined on
> all *mutable* sequence types: almost as simple as your second wording but
> unfortunately misleading since strings also have index.

Which illustrate that the mutable unmutable distinction is not very
usefull to decide whether a sequence could use "index" or not.

>> If someone states: "Show me your use case for using tuple.index and I
>> will show you how to avoid it." or words to that effect I think there
>> is little use trying.
>
> I genuinely cannot think of a use case. I didn't ask you to suggest one so
> I could show you how to avoid it, I asked you to suggest one so that we
> could take the discussion from the purely hypothetical to a more concrete
> discussion of whether it would be a worthwhile enhancement.

I have given a use case in an other article in this thread. Feel free to
comment.

--
Antoon Pardon

Antoon Pardon

unread,
Apr 10, 2007, 9:29:59 AM4/10/07
to

It doesn't because "need" is such a strong word, that just the fact that
you can write your own index function means the method isn't needed.

--
Antoon Pardon

Steve Holden

unread,
Apr 10, 2007, 9:57:00 AM4/10/07
to pytho...@python.org
Paul Boddie wrote:
> On 10 Apr, 11:48, Antoon Pardon <apar...@forel.vub.ac.be> wrote:
>> On 2007-04-10, Duncan Booth <duncan.bo...@invalid.invalid> wrote:
>>
>>> There is a cost to every new language feature: it has to be implemented,
>>> documented, maintained, and above all learned by the users. Good design
>>> involves, in part, not adding to these burdens except where there is a
>>> benefit at least equal to the cost.
>> So what is the easiest to learn: "All sequences have an index method" or
>> "Such and so sequences have an index method and others don't"
>
> I think this observation leads to insights both at the end-user level
> and at the implementer level. Tuples and lists are sequences; the
> index method can be defined generically for all sequences; adding such
> a method to the tuple type can be done with barely any changes to the
> implementation taken from the list type. This leads to the observation
> that a generic index method (defined as a function in the
> implementation) could be made to work with both lists and tuples, and
> that various other methods might also be defined similarly, although
> things like append, extend and other mutating methods wouldn't be
> appropriate for a tuple.
>
A generic definition of index would be tricky, though, if you wanted to
include strings as sequences. In that case you aren't testing for the
presence of a single element but a sub-sequence - I think this change
was introduced in 2.4 to allow checks like

"men" in "three good men"

to succeed where formerly only single characters could be checked for.
One might perversely allow extension to lists and tuples to allow

[3, 4] in [1, 2, 3, 4, 5, 6]

to succeed, but that's forcing the use case beyond normal limits. The
point I am trying to make is that circumstances alter cases, and that we
can't always rely on our intuition to determine how specific methods
work, let alone whether they are available.

I hear the screams of "just add the index() method to tuples and have
done with it" and, to an extent, can sympathize with them. But that way
lies creeping featurism and the next thing you know we'll have a ternary
operator in the language - oh wait, we do now!

>> Which of the above is the easiest to document?
>>
>> Now with implementation and maintaining. If you would start with a class
>> of sequence which classes like tuple and list would inherit from, then
>> there also would be a single function to be implemented and maintained.
>> It would just be usable in more types.
>
> There isn't a "big win" in this case: the intersection of useful
> methods between mutable and immutable sequence types is rather small.
> Nevertheless, providing a slightly deeper abstract class hierarchy
> might be appropriate, and this is being considered for Python 3000.
>
> [...]
>
>> The same happened with the ternary operator. Every use case someone
>> could come up with was rejected by rewriting the code without using
>> a ternary operator. AFAICS the only reason the ternary operator
>> finaly got introduced was because a python developer was bitten by an
>> illusive bug, introduced by one of the idioms that was often used as a
>> way to simulate a ternary operator.
>
> The ternary operator, whilst providing new and occasionally useful
> functionality, is rather "badly phrased" in my opinion: when used,
> it's a bit like reading one natural language and suddenly having the
> grammar of another in use for the rest of the sentence.
>

Indeed the syntax is deliberately "crippled" - Guido's reasoning being,
I believe, that if it were too easy and natural to use then people would
use it inappropriately and too frequently.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

Carsten Haese

unread,
Apr 10, 2007, 10:03:06 AM4/10/07
to pytho...@python.org

Your data is an array. Choosing a data structure that doesn't fit your
data is always going to cause pain. Instead of using struct.unpack, you
should use array.array, and voila!, you get an index method.

-Carsten


Carsten Haese

unread,
Apr 10, 2007, 10:20:31 AM4/10/07
to pytho...@python.org
On Tue, 2007-04-10 at 09:57 -0400, Steve Holden wrote:
> I hear the screams of "just add the index() method to tuples and have
> done with it" and, to an extent, can sympathize with them. But that way
> lies creeping featurism and the next thing you know we'll have a ternary
> operator in the language - oh wait, we do now!

It would indeed be much easier to just give up. However, the resistance
to tuple.index is more than a generic resistance to feature creep. As I
have demonstrated elsewhere on this thread, any use case for tuple.index
will be inherently obfuscated. Code clarity is a major design goal of
Python, and adding tuple.index would be contrary to this goal.

I'm just a user with no influence on the development of Python itself,
but in my humble opinion, the non-existence of tuple.index is more
pythonic than its existence would be.

-Carsten


Paul Boddie

unread,
Apr 10, 2007, 10:27:11 AM4/10/07
to
On 10 Apr, 15:57, Steve Holden <s...@holdenweb.com> wrote:
>
> The point I am trying to make is that circumstances alter cases, and that we
> can't always rely on our intuition to determine how specific methods
> work, let alone whether they are available.

But it's telling that by adopting precisely the implementation that we
currently have for lists, we can have a tuple method which does what
most people would reasonably expect. "Why are we suddenly getting
single characters instead of whole strings?" people have presumably
exclaimed often enough, illustrating that the sequence nature of
strings is a controversial topic. Lists and tuples, however, don't
have such controversial baggage.

> I hear the screams of "just add the index() method to tuples and have
> done with it" and, to an extent, can sympathize with them. But that way
> lies creeping featurism and the next thing you know we'll have a ternary
> operator in the language - oh wait, we do now!

Yes, but the cost of adding index to tuples is minimal, and the mental
cost to programmers is arguably negative. Meanwhile, we now have to
put up with the syntactic bodge that is the ternary operator until the
time comes when it gets deprecated as something that didn't work out
or wasn't really necessary (in Python 4000, perhaps), meaning that we
now have to read third-party code more carefully, the people writing
editors and tools have to change their lexers/parsers again, and so
on.

Paul

Steve Holden

unread,
Apr 10, 2007, 10:57:25 AM4/10/07
to pytho...@python.org
Carsten Haese wrote:
> On Tue, 2007-04-10 at 09:57 -0400, Steve Holden wrote:
>> I hear the screams of "just add the index() method to tuples and have
>> done with it" and, to an extent, can sympathize with them. But that way
>> lies creeping featurism and the next thing you know we'll have a ternary
>> operator in the language - oh wait, we do now!
>
> It would indeed be much easier to just give up. However, the resistance
> to tuple.index is more than a generic resistance to feature creep. As I
> have demonstrated elsewhere on this thread, any use case for tuple.index
> will be inherently obfuscated. Code clarity is a major design goal of
> Python, and adding tuple.index would be contrary to this goal.
>
> I'm just a user with no influence on the development of Python itself,
> but in my humble opinion, the non-existence of tuple.index is more
> pythonic than its existence would be.
>
I quite agree. I was not advocating it as a serious course of action,
more admiring its noise-reduction potential. I'm no great fan of the if
... else expression either, come to that.

BJörn Lindqvist

unread,
Apr 10, 2007, 11:10:07 AM4/10/07
to Carsten Haese, pytho...@python.org
On 4/10/07, Carsten Haese <car...@uniqsys.com> wrote:
> i = p.index(current_player)
> opponents = p[:i-1] + p[i+1:]
>
> An alternative is this:
>
> opponents = tuple(x for x in p if x is not current_player)
>
> You may disagree, but in my opinion, the alternative is better because
> it is a more natural translation of the concept that the opponents of
> the current player are all players that are not the current player.

Your alternative is wrong because it wont raise ValueError if
current_player is not present in the tuple. Please revise your
"solution."


--
mvh Björn

BJörn Lindqvist

unread,
Apr 10, 2007, 11:24:15 AM4/10/07
to Steve Holden, pytho...@python.org
On 4/10/07, Steve Holden <st...@holdenweb.com> wrote:

> Paul Boddie wrote:
> > On 10 Apr, 11:48, Antoon Pardon <apar...@forel.vub.ac.be> wrote:
> >> On 2007-04-10, Duncan Booth <duncan.bo...@invalid.invalid> wrote:
> >>
> >>> There is a cost to every new language feature: it has to be implemented,
> >>> documented, maintained, and above all learned by the users. Good design
> >>> involves, in part, not adding to these burdens except where there is a
> >>> benefit at least equal to the cost.
> >> So what is the easiest to learn: "All sequences have an index method" or
> >> "Such and so sequences have an index method and others don't"
> >
> > I think this observation leads to insights both at the end-user level
> > and at the implementer level. Tuples and lists are sequences; the
> > index method can be defined generically for all sequences; adding such
> > a method to the tuple type can be done with barely any changes to the
> > implementation taken from the list type. This leads to the observation
> > that a generic index method (defined as a function in the
> > implementation) could be made to work with both lists and tuples, and
> > that various other methods might also be defined similarly, although
> > things like append, extend and other mutating methods wouldn't be
> > appropriate for a tuple.
> >
> A generic definition of index would be tricky, though, if you wanted to
> include strings as sequences. In that case you aren't testing for the
> presence of a single element but a sub-sequence - I think this change
> was introduced in 2.4 to allow checks like
>
> "men" in "three good men"
>
> to succeed where formerly only single characters could be checked for.
> One might perversely allow extension to lists and tuples to allow
>
> [3, 4] in [1, 2, 3, 4, 5, 6]
>
> to succeed, but that's forcing the use case beyond normal limits. The

> point I am trying to make is that circumstances alter cases, and that we
> can't always rely on our intuition to determine how specific methods
> work, let alone whether they are available.

I'd love to have that! There are at least one million use cases for
finding a sequence in a sequence and implementing it yourself is
non-trivial. Plus then both list and tuple's index methods would work
*exactly* like string's. It would be easier to document and more
useful. A big win.

> Indeed the syntax is deliberately "crippled" - Guido's reasoning being,
> I believe, that if it were too easy and natural to use then people would
> use it inappropriately and too frequently.

There are no appropriate use cases for that feature. Maybe not for
tuple.index either, but increasing consistency and being able to say
"ALL sequences have an index method that works like THIS" would be a
big win. Unfortunately, it really is the string type that screws up
the symmetry.

--
mvh Björn

Steve Holden

unread,
Apr 10, 2007, 11:29:43 AM4/10/07
to pytho...@python.org
Paul Boddie wrote:
> On 10 Apr, 15:57, Steve Holden <s...@holdenweb.com> wrote:
>> The point I am trying to make is that circumstances alter cases, and that we
>> can't always rely on our intuition to determine how specific methods
>> work, let alone whether they are available.
>
> But it's telling that by adopting precisely the implementation that we
> currently have for lists, we can have a tuple method which does what
> most people would reasonably expect. "Why are we suddenly getting
> single characters instead of whole strings?" people have presumably
> exclaimed often enough, illustrating that the sequence nature of
> strings is a controversial topic. Lists and tuples, however, don't
> have such controversial baggage.
>
You can call something non-controversial when it generates a thread like
this? :-) It's really a storm in a teacup. The acid test would be to
generate a patch that added the method and then see if you could get a
committer to commit it. All else (including my own contributions) is
mere hot air.

>> I hear the screams of "just add the index() method to tuples and have
>> done with it" and, to an extent, can sympathize with them. But that way
>> lies creeping featurism and the next thing you know we'll have a ternary
>> operator in the language - oh wait, we do now!
>
> Yes, but the cost of adding index to tuples is minimal, and the mental
> cost to programmers is arguably negative. Meanwhile, we now have to
> put up with the syntactic bodge that is the ternary operator until the
> time comes when it gets deprecated as something that didn't work out
> or wasn't really necessary (in Python 4000, perhaps), meaning that we
> now have to read third-party code more carefully, the people writing
> editors and tools have to change their lexers/parsers again, and so
> on.
>

What can I say? Every language has warts. Some people were as anxious to
see if ... else (which I regard as a wart) put in as others are to see
tuple.index().

Carsten Haese

unread,
Apr 10, 2007, 11:44:16 AM4/10/07
to pytho...@python.org

You have a point. Here is my revised solution:

assert current_player in p


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

The added advantage is that AssertionError is better than IndexError for
conveying that a severe program bug has occurred.

-Carsten


Carsten Haese

unread,
Apr 10, 2007, 11:47:05 AM4/10/07
to pytho...@python.org

_.replace("IndexError", "ValueError"), of course.

-Carsten


Paul Boddie

unread,
Apr 10, 2007, 11:57:16 AM4/10/07