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

> Duck-typing allows natural access to polymorphism. You appear to be 
> making semantic distinctions merely for the sake of continuing this 
> rather fatuous thread.

I gave an argument that showed that the specific way the in
functionality was extended in strings makes duck-typing (and
by extention natural access to polymorphism) more difficult.
although it may do so in a way that is not significant to
you and the other developers. 

Now if you don't agree with the argument presented that
is fine with me. If you think the problem is not big 
enough to bother with, that is fine with me too.
But the argument doesn't disappear simply because you
think ill of my intentions.

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.

>> Suppose someone writes a function that acts on a sequence.
>> The algorithm used depending on the following invariant.
>> 
>>   i = s.index(e) => s[i] = e
>> 
>> Then this algorithm is no longer guaranteed to work with strings.
>> 
> Because strings have different properties than other sequences. I can't 
> help pointing out that your invariant is invalid for tuples also, 
> because tuples don't have a .index() method.

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.

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.

-- 
Antoon Pardon