From: John Carter Date: 2005-01-20T06:26:28+09:00 Subject: Let's go Ape! Monkey typing] No, I'm not trying to make a monkey out of you, there really is a genuine proposal to extend duck typing with monkey typing. http://peak.telecommunity.com/DevCenter/MonkeyTyping Abstract Python has always had "duck typing": a way of implicitly defining types by the methods an object provides. The name comes from the saying, "if it walks like a duck and quacks like a duck, it must be a duck". Duck typing has enormous practical benefits for small and prototype systems. For very large frameworks, however, or applications that comprise multiple frameworks, some limitations of duck typing can begin to show. This PEP proposes an extension to "duck typing" called "monkey typing", that preserves most of the benefits of duck typing, while adding new features to enhance inter-library and inter-framework compatibility. The name comes from the saying, "Monkey see, monkey do", because monkey typing works by stating how one object type may mimic specific behaviors of another object type. In particular, I like this quote... As Guido acknowledged in his optional static typing proposals, having type declarations check argument types based purely on concrete type or conformance to interfaces would stifle much of Python's agility and flexibility. However, if type declarations are used instead to adapt objects to an interface expected by the receiver, Python's flexibility could in fact be improved by type declarations. Also important are the notions of composition of adaptors and that there are two types of adaption... Over a long period of time, it became clear that there are really two fundamentally different types of adaptation that are in common use. One type is the "extender", whose purpose is to extend the capability of an object or allow it to masquerade as another type of object. An "extender" is not truly an object unto itself, merely a kind of "alternate personality" for the object it adapts. For example, a power transformer might be considered an "extender" for a power outlet, because it allows the power to be used with different devices than it would otherwise be usable for. By contrast, an "independent adapter" is an object that provides entirely different capabilities from the object it adapts, and therefore is truly an object in its own right. While it only makes sense to have one extender of a given type for a given base object, you may have as many instances of an independent adapter as you like for the same base object. For example, Python iterators are independent adapters, as are views in a model-view-controller framework, since each iterable may have many iterators in existence, each with its own independent state. Resuming the previous analogy of a power outlet, you may consider independent adapters to be like appliances: you can plug more than one lamp into the same outlet, and different lamps may be on or off at a given point in time. Many appliances may come and go over the lifetime of the power outlet -- there is no inherent connection between them because the appliances are independent objects rather than mere extensions of the power outlet. A key distinction between extenders and independent adapters is the "as a" relationship versus the "has a" relationship. An iterable "has" iterators and a model "has" views. But an extender represents an "as a" relationship, like treating a Person "as an" Employee, or treating a string "as a" filename. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand "The notes I handle no better than many pianists. But the pauses between the notes - ah, that is where the art resides!' - Artur Schnabel