On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:

> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't need to test whether something is callable".

A common Python idiom is to take different actions based on the capabilities
of an object rather than its type. 'Duck Typing' is a special case of this, and
I think it's a fairly powerful technique (and deserving of more respect than
most language purists are willing to grant it.)

Duck typing isn't "ask the object whether it can do this". Duck typing is "do this". I don't believe 'taking different actions based on capabilities' is all that common, and it certainly breaks easily. The only 'different action' you should contemplate is 'raising an error', and calling an uncallable object does that for you. As Greg suggests, if you don't know whether you're supposed to call a passed-in object, or add it to another object, or index it with another object, or use it as a class to instantiate, you need to redesign your API. The caller knows how this object should be handled, knows what it wants your code to do with it, and passing it in saying "guess what I want done" is just throwing away useful information.

It may be 'common' for programmers to try and write this kind of code (accept either a string or an instance, a sequence or a single object, etc) but it's certainly not a common idiom -- idioms don't suck :-)

--
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to