[Patches] [ python-Patches-403693 ] tupleobject.c: implement tuple.index() and tuple.count()

[SourceForge.net]

Patches item #403693, was opened at 2001-02-08 17:05
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Markus F.X.J. Oberhumer (mfx)
Assigned to: Nobody/Anonymous (nobody)
Summary: tupleobject.c: implement tuple.index() and tuple.count()

Initial Comment:
This patch adds support for two methods that are useful for immutable tupels, namely index() and count(). The semantics is exactly like those on list objects.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2005-11-27 20:27

Message:
Logged In: YES 
user_id=6380

The answer is still no.

If you don't appreciate the difference in purpose between
lists and tuples perhaps you should go ask about this on
c.l.py instead of arguing on SF.

----------------------------------------------------------------------

Comment By: Christoph Zwerschke (cito)
Date: 2005-11-27 19:24

Message:
Logged In: YES 
user_id=193957

I really do not understand why this fix was rejected.

Why should Python programmers have to bother about casting
sequences to lists and be punished with runtime errors if
they forget doing, so if this could easily be avoided? I
think it is an unnecessary stumbling block. If I know that
lists and strings have index and count methods, I simply
expect that this is a rule for all sequence types and tuples
have them as well. So it contradicts "special cases aren't
special enough to break the rules", the "principle of least
astonishment" and orthogonal design.

Only the following reasons were given:

1) "index" and "count" are "list-ish" things:

I dare to disagree. "index" and "count" are not "list-ish"
things, they are "sequence-ish" things. Actually they have
been implemented for strings as well. Why should they only
make sense for mutable sequence types and not for immutable
sequences types such as tuples?

2) Python will become too large by adding this fix:

Even if there is no code-reuse between lists and tuples,
would adding these few bytes really hurt so much? Isn't it
better to waste some bytes if you can improve orthogonality
and convenience for programmers? How much cost a handfull of
bytes today?

Fixing the doco wouldn't be a big deal either. The
explanation of "index" and "count" could simply move from
the section "mutable sequence types" to "sequence types",
plus maybe a remark that they show an extended behavior for
strings (they look for substrings as well) and do not exist
for xrange (where they are really not needed).


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-16 03:21

Message:
Changed Status from Closed to Rejected, and assigned to None, in accord with rejection procedure.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-15 08:49

Message:
Why bother?  I like the fact that when you want to do list-ish things you have to use lists.  Use list(t).count(x) if you really want this for a tuple.

I'm rejecting this in the name of all those users who want Python to be small.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-02-09 19:13

Message:
interested in adding this to 2.1?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470