At 12:02 AM 12/2/2006 +0200, tomer filiba wrote: >i'm +1 on that, but still, as Guido (and others) said, you need a way to >differentiate a sequence from a mapping, or a list from a string. dispatching >based on *concrete types*, i.e., isinstance(x, dict), is bad, as it means >users *must derive* from dict in order to be dispatched as *dict-like*
No, it merely means that they must register for the desired *behavior*. If they want the same thing to happen for that type as for a dict, then let them register it explicitly. (e.g. someop[mytype] = someop[dict]) Thinking about things as being "dict-like" (and then desiring to drive if-then tests off of that) is actually the source of the *problem*, not the solution. Guido has argued that it's verbose to have to do this for lots and lots of operations, but I've not observed any situations in practice where this was actually required. What usually happens is that concrete type dispatching perfectly suffices for builtin types and types native to the library that defines the operation. Integrating that library with other types then requires registration of the few special cases that are relevant for *dispatching* (versus simply passing in objects that conform to the required duck typing). Thus, interface checking is a duck in wolf's clothing: it looks like it's an improvement over duck typing or concrete type checks, but actually isn't. In fact, it's worse because it entices people to use it because it *looks* "safer" than concrete type checking! (i.e. it appears more extensible, less error-prone, etc., when it's actually no different in these respects.) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
