tuples, index method, Python's design

[Antoon Pardon]

On 2007-04-13, Steve Holden <steve at holdenweb.com> wrote:
> Antoon Pardon wrote:
>> On 2007-04-13, Steve Holden <steve at holdenweb.com> wrote:
>>> Antoon Pardon wrote:
>>>> On 2007-04-12, Carsten Haese <carsten at uniqsys.com> wrote:
>>>>> On Thu, 2007-04-12 at 14:10 +0000, Antoon Pardon wrote:
>>>>>> People are always defending duck-typing in this news group and now python
>>>>>> has chosen to choose the option that makes duck-typing more difficult.
>>>>> Au contraire! The "inconsistent" behavior of "in" is precisely what
>>>>> duck-typing is all about: Making the operator behave in a way that makes
>>>>> sense in its context.
>>>> No it isn't. Ducktyping is about similar objects using a similar
>>>> interface to invoke similar behaviour and getting similar result.
>>>>
>>>> So that if you write a function you don't concern yourself with
>>>> the type of the arguments but depend on the similar behaviour.
>>>>
>>> Please note that "similar" does not mean "exact".
>> 
>> That is because I don't want to get down in an argument about
>> whether tp[:3] and ls[:3] is similar behaviour or exact the
>> same behaviour when tp is a tuple and ls is a list.
>> 
>>> The behavior of str.__contains__ and list.__contains__ is similar.
>> 
>> That would depend on how much you find things may differ and
>> still call them similar. IMO they are not similar enough
>> since "12" in "123" doesn't behave like [1,2] in [1,2,3]
>> 
> And it never will, because of the property of strings I mentioned 
> previously. Unless you want to introduce a character type into Python 
> there is no way that you are ever going to be be satisfied.

The properties of strings didn't force the developers to make those
two behave differently. They could have made the choice that "12"
in "123" returned False and could have introduced a method that would
return True or False depending on whether the argument was a substring
or not. The same method could then eventually be used in other sequences
to test whether the argument was a subsequence or not. Either by
the python-developers themselves if they ever thought that usefull
or by any programmer who could add this functionality to a subclass.

Yes the properties of strings allowed for the solution the python
developers have chosen, a solution not extendable to other
sequence types. So yes [1,2] in [1,2,3] will never behave like "12" in
"123" currently does and the properties of strings allowed it to evolve this way
but in the end it was a design choice that could have been made differently
and could have been made in a way to allow more duck typing and more
access to polymorphism.

>> And consider that each small inconsistency in itself
>> may be not important enough to remove. But if you
>> have enough of them remembering all these special
>> cases can become tedious.
>> 
> But not as tedious as this eternal discussion of already-decided issues.

A number of those "decided" issue have been changed. Besides
nobody is forcing you to participate. If you think these
kind of issues is too tedious for your taste, feel free
to no longer participate.

>> Strings have some properties that are different and some
>> properties that are similar with other sequences. My argument
>> is that if you want to facilitate duck typing and natural access to 
>> polymorphism in peoples functions that work with sequences in general
>> you'd better take care that the sequence api of strings resembles
>> the sequence api of other sequences as good as possible.
>> 
> This is just a bald restatement of the same argument you feel makes it 
> desirable to add an index() method to tuples.

No it is not a bald statement. If tuple would have methods like index
and count, more functions could be written that are indifferent to
the argument being a tuple or a list or at least it would make
writing such a function easier, so it would allow for more
duck typing and give more access to polymorphism.

You may think this kind of duck typing and polymorphism insignificant
but that doesn't change the truth about the above statement.

> If taken to its logical 
> (and ridiculous) extreme there should only be one sequence type in Python.

No it doesn't. There is a big difference between having sequences with
different properties because there is a need for those different
properties and making things more different than needed and using
the need for different properties to introduce differences that are
unnecessary.

>> You on the other hand seem to argue that since strings have
>> properties where they differ from other sequences it no longer
>> is so important that the sequence api of strings resembles those
>> of other sequences.
>> 
> Well, of course. Programming languages are for human users, and they 
> should do what human users find most natural. Since humans can disagree 
> the developers (amongst who I do not count myself, although I *am* 
> concerned about the development of Python) have to try and go by 
> consensus, which by and large they do reasonably successfully.

But the defence of not having tuple.index has never been about
what was natural to the user or not, but has always been about what
tuples were supposedly intended for. 

> So what I suppose I *am* saying is that your opinions would seem to 
> differ from the consensus. While you are not in a minority of one you 
> are in a minority, and it would be nice if we could proceed without 
> having to continually revisit each small design decision on a continuous 
> basis.

I am not so sure I'm in a minority. This kind of thing is not decided by
consensus at least not among the python users. It is the sole decision of
the BDFL. Besides, this is usenet, all kind of things get revisted here on
a continuous basis. Why should design decisions be an exception?

-- 
Antoon Pardon