On 2007-04-13, Steve Holden <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> 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. >> > 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 -- http://mail.python.org/mailman/listinfo/python-list
