tuples, index method, Python's design

[Antoon Pardon]

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.

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.


On the other hand I subclass list and add a sub method
to check for the argument being a sublist of the object.
Now I write a function that depends on this functionality.
But although strings have the functionality I can't use
them as argument because the functionality is invoked
in a different way.

> Nobody seems to be complaining about "+" behaving
> "inconsistently" depending on whether you're adding numbers or
> sequences.

You are wrong. I already mentioned problems with it. The
problem is that there are structures that are numbers and
sequences at the same time. So I have a choice. Either I
overload the "+" to get an addition or to get a concatanation.

In the first case I can't trust my structure to work with
functions that expect a general sequence because they
may depend on the fact that "+" concatenates. In the
other case I can't trust my structure to work with
numbers because they may depend on the fact that "+"
behaves like an addition.

-- 
Antoon Pardon