Talin <[EMAIL PROTECTED]> writes:
> OK, so I hope I have established the requirement for duck typing.
> Now, I want to establish the requirement for interface discovery
> or 'type testing'.
These two are mutually incompatible. At least if we expect libraries
to be reliable and robust.
Python must decide one or the other: either interfaces are informal
and fuzzy, but we can't dispatch on them, and operation names are
quite explicit about how they treat their arguments; or interfaces
are named and explicitly declared, usable for testing and dispatching,
and operations are quite easily overloaded. Or some interfaces are
done in one way and some in the other, but they can't be mixed.
> Now, generic functions are good at dealing with these kinds of
> situations. However, generic functions (as they are usually
> concieved) can only deal with specific, concrete types, not
> "types which satisfy some constraint".
This is not without reasons. Generic functions need a sharp notion
of supported interfaces. Either there is a reliable way to tell a
dictionary from a sequence, or there is not. Either approach leads
to a coherent language, but not both.
Explicitly declared interfaces have a partial order, which is useful
for dispatch. There is little hope for inferring inclusions among
arbitrary predicates.
> Thus we have a tension between duck types and type testing;
> Unfortunately, punting on this issue (i.e. saying "you can't do type
> testing on duck types") isn't a good option - both techniques are
> just too darn useful to say that you can't use them together.
Sorry, I believe this is the only possible option, and you are seeking
impossible.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_______________________________________________
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
