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. -- http://mail.python.org/mailman/listinfo/python-list