andreengels at gmail.com
Sat Jun 2 06:46:10 CEST 2007
2007/6/1, Warren Stringer <warren at muse.com>:
> 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
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, andreengels at gmail.com
ICQ: 6260644 -- Skype: a_engels
More information about the Python-list