tuples, index method, Python's design

[Antoon Pardon]

On 2007-04-06, Carsten Haese <carsten at uniqsys.com> wrote:
> On Fri, 2007-04-06 at 11:33 -0700, 7stud wrote:
>> On Apr 6, 7:56 am, "Paul Boddie" <p... at 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