On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list