tuples, index method, Python's design

[Steve Holden]

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.

>> 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. 
> 
I am not "a developer".

> 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.
> 
Apparently.

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

>>> 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.
> 
This is just a bald restatement of the same argument you feel makes it 
desirable to add an index() method to tuples. If taken to its logical 
(and ridiculous) extreme there should only be one sequence type in Python.

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

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.

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