Type Hinting vs Type Checking and Preconditions

[Jay Parlar]

On Mar 8, 2006, at 7:20 AM, Tom Bradford wrote:

> Really what we're talking about here is weak typing in the form of
> optional type hinting performed on a function by function basis.  As an
> option, what it would do is allow an author to semantically 'hint' to
> the interpreter that a function is expecting a certain type, and
> perform any implicit conversion if the passed type is not what was
> expected, thus translating to a semantically expected result.
>

So how would that system deal with this?

class A(object):
     def foo(self):
         print "bar"

class B(object):
     def foo(self):
         print "bar"

def typedfunction(x : A):
     x.foo()

b = B()
typedfunction(b) #Your system would probably consider this an error


This is an example of why type checking/hinting is no good, as it would 
break duck typing.

  In terms of their definitions, A and B have nothing in common (ie. B 
is not a subclass of A), yet I should be able to use instances of 
either one, whenever the method 'foo' is expected. Type hinting would 
completely break that. This again is why I point you in the direction 
of PEP 246.

>
> The fact is, that with a system such as this, you could just 'not use
> it', and none would be the wiser, as it's an authorship extension
> rather than a calling extension.  What I was suggesting is that nothing
> change other than function/method prototypes, and that everything,
> everwhere, at all times continues to be represented as scalars.

The problem is when someone decides to use this option, and releases a 
library with it. Now everyone who wants to use this library is forced 
to use this type hinting. It would create a divide in available Python 
code. (Of course, adaption would result in the same issue, but I 
*think* more people would be willing to use adaption, as it doesn't 
break duck typing).

Jay P.