Tom Bradford skrev: > Really what we're talking about here is weak typing in the form of
Careful with the terminology! Weak typing is something else entirely. > 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. But is it adaptation or some weaker form of that concept, where "x : int" just means that you call the "int" function on "x" to coerce it (with an exception raised if that doesn't work), or is it more of a type-checking system, where you call "isinstance(x, int)" and raise an exception if that test returns false? > It is my feeling that this doesn't represent a sea-change in the way > Python does things, and it's certainly *not* the way things are done in > Java or C++, as both of those languages are strongly typed, wherein you > can't even pass a parameter if it isn't of the expected type, or a > subclass thereof. Careful with the terminology, again! That calling a function with the wrong type of argument ultimately leads to a run-time exception is actually a sign that Python also has strong typing - it just doesn't enforce particular argument types when actually calling a function or method (but typically instead when looking up attributes and methods on objects). Certainly, explicit type-checking (the second case above) is different from how Python currently does things (except for a few low-level calls), whereas some form of coercion is not the same as how Python currently behaves, since passing an object of some previously-unknown numeric type into a function which performs multiplication wouldn't result in the conversion of that object into an int or float, for example. > 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. I don't follow the scalars reference - sounds like Perl terminology to me - but whilst "x : int" might be convenient notation for either type-checking or coercion/adaptation, the problem would soon arise where paranoid developers add such notation to their code in order to insist that only types that they can think of be used with their APIs. The consequence would be arbitrary limits on extensibility - you'd actually have to update code to work with new or previously-unconsidered kinds of objects - and with this, you'd soon be "the wiser" about usage of the feature in question. As C++ has shown, when designing exotic notations to describe types, you end up with a language in itself to do that job; at which point you might arguably be better served by either writing your type declarations in Python rather than starting with an insufficient mini-language which grows into a monster or, as I'd rather like to imagine, employing alternative approaches to deal with program analysis. Paul -- http://mail.python.org/mailman/listinfo/python-list
