By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,829 Members | 1,828 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,829 IT Pros & Developers. It's quick & easy.

"index" method only for mutable sequences??

P: n/a
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
Apr 6 '07 #1
Share this Question
Share on Google+
122 Replies


P: n/a

C.L. wrote:
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 (Gu**************@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>

Apr 6 '07 #2

P: n/a
C.L. wrote:
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
Apr 6 '07 #3

P: n/a
James Stroud <jstroud <atmbi.ucla.eduwrites:
>
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.

Apr 6 '07 #4

P: n/a
C.L. wrote:
James Stroud <jstroud <atmbi.ucla.eduwrites:
>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

Apr 6 '07 #5

P: n/a
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....e89128bdeb59c0

[...]
*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

Apr 6 '07 #6

P: n/a
On Apr 6, 7:56 am, "Paul Boddie" <p...@boddie.org.ukwrote:
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.
Apr 6 '07 #7

P: n/a
C.L. wrote:
James Stroud <jstroud <atmbi.ucla.eduwrites:
>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.
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
Apr 6 '07 #8

P: n/a
On Fri, 2007-04-06 at 11:33 -0700, 7stud wrote:
On Apr 6, 7:56 am, "Paul Boddie" <p...@boddie.org.ukwrote:
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.

-Carsten
Apr 6 '07 #9

P: n/a
On Apr 6, 1:24 pm, Carsten Haese <cars...@uniqsys.comwrote:
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.
Apr 7 '07 #10

P: n/a
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

Apr 7 '07 #11

P: n/a
On Sat, 2007-04-07 at 06:45 -0700, be************@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
Apr 7 '07 #12

P: n/a
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

Apr 7 '07 #13

P: n/a
On Apr 7, 8:27 am, Carsten Haese <cars...@uniqsys.comwrote:
On Sat, 2007-04-07 at 06:45 -0700, bearophileH...@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
I'll trade you an index method for tuples for the whole complex number
facility.

Apr 7 '07 #14

P: n/a

"Carsten Haese" <ca*****@uniqsys.comwrote in message
news:ma***************************************@pyt hon.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
Apr 8 '07 #15

P: n/a
On Sun, 08 Apr 2007 02:40:52 GMT, Alan Isaac wrote
"Carsten Haese" <ca*****@uniqsys.comwrote in message
news:ma***************************************@pyt hon.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

Apr 8 '07 #16

P: n/a
be************@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...70&atid=305470

Paul

Apr 8 '07 #17

P: n/a
Carsten Haese <ca*****@uniqsys.comwrites:
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?
Apr 8 '07 #18

P: n/a
7stud wrote:
On Apr 7, 8:27 am, Carsten Haese <cars...@uniqsys.comwrote:
>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.

Apr 8 '07 #19

P: n/a
On Sun, 2007-04-08 at 07:51 -0700, Paul Rubin wrote:
Carsten Haese <ca*****@uniqsys.comwrites:
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. 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
Apr 8 '07 #20

P: n/a
Carsten Haese <ca*****@uniqsys.comwrites:
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.
Apr 8 '07 #21

P: n/a
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
Apr 8 '07 #22

P: n/a
On Sun, 2007-04-08 at 13:10 -0700, Paul Rubin wrote:
Carsten Haese <ca*****@uniqsys.comwrites:
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__?

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
Apr 9 '07 #23

P: n/a
Carsten Haese <ca*****@uniqsys.comwrites:
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.
Apr 9 '07 #24

P: n/a
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 <ca*****@uniqsys.comwrites:
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.

Apr 9 '07 #25

P: n/a
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
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.
Apr 9 '07 #26

P: n/a
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).

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

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

James
Apr 9 '07 #27

P: n/a
On Mon, 09 Apr 2007 02:26:37 +0000, James Stroud wrote:
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).

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

Impossible? I wouldn't even say that this was all that difficult.
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.

Apr 9 '07 #28

P: n/a
Steven D'Aprano wrote:
On Mon, 09 Apr 2007 02:26:37 +0000, James Stroud wrote:
>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).

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

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

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

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
Apr 9 '07 #29

P: n/a
Paul Rubin schrieb:
Carsten Haese <ca*****@uniqsys.comwrites:
>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

Apr 9 '07 #30

P: n/a
Paul Rubin schrieb:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>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.
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

Apr 9 '07 #31

P: n/a
On Sun, 08 Apr 2007 22:20:45 -0700, James Stroud wrote:
Steven D'Aprano wrote:
>On Mon, 09 Apr 2007 02:26:37 +0000, James Stroud wrote:
>>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).

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

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

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


def __setitem__(self, *args):
raise TypeError, '%s doesn't support item assignment.' %
self.__class__.__name__
Problem fixed. Next?
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.

Apr 9 '07 #32

P: n/a
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
Apr 9 '07 #33

P: n/a
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
Apr 9 '07 #34

P: n/a
Steven D'Aprano wrote:
On Sun, 08 Apr 2007 22:20:45 -0700, James Stroud wrote:

>>Steven D'Aprano wrote:
>>>On Mon, 09 Apr 2007 02:26:37 +0000, James Stroud wrote:
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).

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

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

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


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


hl.reverse()
hl.sort() # if the list isn't already sorted
del hl[0]
hl.append()
etc.
Yes, you can block those as well...
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
Apr 10 '07 #35

P: n/a
On 2007-04-06, Carsten Haese <ca*****@uniqsys.comwrote:
On Fri, 2007-04-06 at 11:33 -0700, 7stud wrote:
>On Apr 6, 7:56 am, "Paul Boddie" <p...@boddie.org.ukwrote:
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
Apr 10 '07 #36

P: n/a
On 2007-04-08, Carsten Haese <ca*****@uniqsys.comwrote:
On Sun, 2007-04-08 at 07:51 -0700, Paul Rubin wrote:
>Carsten Haese <ca*****@uniqsys.comwrites:
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
Apr 10 '07 #37

P: n/a
On 2007-04-09, Georg Brandl <g.******@gmx.netwrote:
Paul Rubin schrieb:
>Carsten Haese <ca*****@uniqsys.comwrites:
>>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
Apr 10 '07 #38

P: n/a
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>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.
Apr 10 '07 #39

P: n/a
On 2007-04-10, Duncan Booth <du**********@invalid.invalidwrote:
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>>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
Apr 10 '07 #40

P: n/a
On 10 Apr, 11:48, Antoon Pardon <apar...@forel.vub.ac.bewrote:
On 2007-04-10, Duncan Booth <duncan.bo...@invalid.invalidwrote:
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

Apr 10 '07 #41

P: n/a
On 2007-04-10, Paul Boddie <pa**@boddie.org.ukwrote:
>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
Apr 10 '07 #42

P: n/a
On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote
On 2007-04-06, Carsten Haese <ca*****@uniqsys.comwrote:
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

Apr 10 '07 #43

P: n/a
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

Apr 10 '07 #44

P: n/a
On 2007-04-10, Carsten Haese <ca*****@uniqsys.comwrote:
On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote
>On 2007-04-06, Carsten Haese <ca*****@uniqsys.comwrote:
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
Apr 10 '07 #45

P: n/a
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
On 2007-04-10, Duncan Booth <du**********@invalid.invalidwrote:
>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.
Apr 10 '07 #46

P: n/a
On Tue, 2007-04-10 at 12:29 +0000, Antoon Pardon wrote:
On 2007-04-10, Carsten Haese <ca*****@uniqsys.comwrote:
On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote
On 2007-04-06, Carsten Haese <ca*****@uniqsys.comwrote:
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
Apr 10 '07 #47

P: n/a
On 2007-04-10, Duncan Booth <du**********@invalid.invalidwrote:
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>On 2007-04-10, Duncan Booth <du**********@invalid.invalidwrote:
>>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
Apr 10 '07 #48

P: n/a
On 2007-04-10, Carsten Haese <ca*****@uniqsys.comwrote:
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.
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
Apr 10 '07 #49

P: n/a
On 2007-04-10, Carsten Haese <ca*****@uniqsys.comwrote:
>
>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.
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
Apr 10 '07 #50

122 Replies

This discussion thread is closed

Replies have been disabled for this discussion.