[Python-3000] PEP 3100 Comments
Thomas Wouters
thomas at python.org
Sun May 7 09:41:54 CEST 2006
On 5/7/06, Talin <talin at acm.org> 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 <thomas at python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060507/5c8d038e/attachment-0001.htm
More information about the Python-3000
mailing list