Adding static typing to Python

[Alexander Jerusalem]

In a static type system I would use an interface to tell everyone who wants 
to use my function: If you want to use this function, give your object this 
interface and everything will be fine. No one has to look at my code to 
find out what they have to provide for to use my function. But I agree with 
you that it'd be even better if it wasn't necessary to provide a fixed 
interface, that forces you to implement all the methods even though the 
function you want to use only makes use of one of them.

In the paper you cite, the author speaks of the detection of protocols and 
wrappers. I'm completely sure if he intends this to be a dynamic process at 
runtime or a kind of "compile-time" tool. I can imagine using it both at 
runtime and to check a code base.

But there's another feature of static typing that I find extremely useful 
and that's type based dispatching, ideally multi methods. And that's not 
covered by dynamic protocoll detections as suggested in the paper as far as 
I understand it.

Regards,
Alexander

At 08:50 21.02.2002 +0100, Laura Creighton wrote:
> > Alexander Jerusalem:
> > The proposals of the types-SIG say that static typing is used on a per
> > module basis. That means that weather there is or is not a performance
> > improvement it's only going to affect you if you choose to use the
> > static types.
> >
> > Alexander
>
>The problem is that static typing effects everybody in terms of code
>reusability.  Let us say you make a terrific function which works on
>a string.  And in some way you specify that, yes, the first and only
>argument to this function is a string.
>
>Now, let us assume I love your function and want to use it a lot.
>But I want to use it on my own objects which are in some way 'string
>like'.  Right now I have to read your code, and determine what
>were the properties of a string you used, to determine whether my
>stringlike object can already be used with your function.  I would
>like to automate this, and be able to interrogate both your function
>and my object and get a result  'will work' or 'won't work: reason
>object does not have an islower method which function requires' and
>the like.
>
>What I don't want to have to do is rewrite the code, because
>Alexander Jerusalem was only thinking about strings when he wrote it.
>Static type checking makes you think that 'strings' and 'ints' and the
>like a real meaningful things rather than a convenient shorthand for
>'is a sequence and has the following methods':
>
>['capitalize', 'center', 'count', 'encode', 'endswith', 'expandtabs', 'find',
>  'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace', 'istitle',
>  'isupper', 'join', 'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex',
>  'rjust', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase',
>  'title', 'translate', 'upper']
>
>See 'PEP 246: Object Adaptation - (Clark C. Evans)'
>http://python.sourceforge.net/peps/pep-0246.html  for one attempt to
>get the safety you want without the restriction I don't.
>
>Laura Creighton