duck-type-checking?

[George Sakkis]

On Nov 13, 10:55 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:

> Take this example:
>
> def foo(alist):
>     alist.sort()
>     alist.append(5)
>
> The argument can be any object with sort and append methods (assumed to
> act in place). But what happens if you pass it an object with a sort
> method but no append? The exception doesn't occur until *after* the
> object is sorted, which leaves it in an inconsistent state. This can be
> undesirable: you might need the function foo to be atomic, either the
> entire function succeeds, or none of it.

In this example atomicity is not guaranteed even if alist is a builtin
list (if it contains a complex number or other unorderable object),
let alone if not isistance(alist, list). It gets worse: false
positives are less likely for full-spelled methods with well-known
names such as "sort" and "append"  (i.e. if hasattr(alist, 'append'),
alist.append *probably* does what you think it does), but good luck
with that when testing for __getitem__, __iter__ for more than one
pass, __call__, and other special methods with ambiguous or undefined
semantics.

Let's face it, duck typing is great for small to medium complexity
projects but it doesn't scale without additional support in the form
of ABCs/interfaces, explicit type checking (at compile and/or run
time), design by contract, etc. It must not be a coincidence that both
Zope and Twisted had to come up with interfaces to manage their
massive (for Python at least) complexity.

George