Type Hinting vs Type Checking and Preconditions

[Paul Boddie]

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