2007/6/1, Warren Stringer <[EMAIL PROTECTED]>: > I am not insisting on anything. I use ``c[:]()`` as shorthand way of saying > "c() for c in d where d is a container" > > Having c() support containers seems obvious to me. It jibes with duck > typing. Perhaps the title of this thread should have been: "Why don't > containers quack?" > > A change is surprising only if it breaks something. I still haven't seen any > code that breaks by making such a change. Seeing such code would teach a > great deal.
I think it very much bites duck typing. Currently, if I try to execute a string or a list or whatever, I get: TypeError: 'str' object is not callable But under your proposed semantics, suppose a is a list with some executable and some non-executable elements. What should a() now give? It cannot be a TypeError, because a list (in your semantics) is callable. Whatever error it gives, and whether or not the preceding executables are executed first, it will not be an existing error acting the way it normally does - there is no Python error for "you cannot do this with this object, but you can do it with other objects of the same type". And that does not seem to be a case of "We have never needed it yet" - the join method seems to have been specifically tailored so that no such error is needed. -- Andre Engels, [EMAIL PROTECTED] ICQ: 6260644 -- Skype: a_engels -- http://mail.python.org/mailman/listinfo/python-list
