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
