[Python-Dev] "Monkey Typing" pre-PEP, partial draft

[Phillip J. Eby]

I just attempted to post the Monkey Typing draft pre-PEP, but it bounced 
due to being just barely over the size limit for the list.  :)

So, I'm just posting the preamble and abstract here for now, and a link to 
a Wiki page with the full text.  I hope the moderator will approve the 
actual posting soon so that replies can quote from the text.

=== original message ===

This is only a partial first draft, but the Motivation section nonetheless 
attempts to briefly summarize huge portions of the various discussions 
regarding adaptation, and to coin a hopefully more useful terminology than 
some of our older working adjectives like "sticky" and "stateless" and 
such.  And the specification gets as far as defining a simple 
decorator-based syntax for creating operational (prev. "stateless") and 
extension (prev. "per-object stateful") adapters.

I stopped when I got to the API for declaring volatile (prev. per-adapter 
stateful) adapters, and for enabling them to be used with type 
declarations, because Clark's post on his revisions-in-progress seem to 
indicate that this can probably be handled within the scope of PEP 246 
itself.  As such, this PEP should then be viewed more as an attempt to 
formulate how "intrinsic" adapters can be defined in Python code, without 
the need to manually create adapter classes for the majority of 
type-compatibility and "extension" use cases.  In other words, the 
implementation described herein could probably become part of the front-end 
for the PEP 246 adapter registry.

Feedback and corrections (e.g. if I've repeated myself somewhere, spelling, 
etc.) would be greatly appreciated.  This uses ReST markup heavily, so if 
you'd prefer to read an HTML version, please see:

http://peak.telecommunity.com/DevCenter/MonkeyTyping

But I'd prefer that corrections/discussion quote the relevant section so I 
know what parts you're talking about.  Also, if you find a place where a 
more concrete example would be helpful, please consider submitting one that 
I can add.  Thanks!


PEP: XXX
Title: "Monkey Typing" for Agile Type Declarations
Version: $Revision: X.XX $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Phillip J. Eby <pje at telecommunity.com>
Status: Draft
Type: Standards Track
Python-Version: 2.5
Content-Type: text/x-rst
Created: 15-Jan-2005
Post-History: 15-Jan-2005

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.

Monkey typing can also potentially form the basis for more sophisticated type
analysis and improved program performance, as it is essentially a simplified
form of concepts that are also found in languages like Dylan and Haskell.  It
is also a straightforward extension of Java casting and COM's QueryInterface,
which should make it easier to represent those type systems' behaviors within
Python as well.

[see the web page above for the remaining text]