J
John Carter
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 : (e-mail address removed)
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
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 : (e-mail address removed)
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
.