Compile-time type checking (was Re: Typing system vs. Java)
peter at engcorp.com
Tue Jul 31 07:49:32 CEST 2001
Donn Cave wrote:
> If you a type checking compiler, the object would have to agree at
> compile time with the programmer's notion of what would be an
> appropriate input.
Sometimes the programmer's notion of "appropriate input" is
a little restrictive. Sometimes it is better not to have type-checking
at compile time, but to do it at run time. When a library routine
is used for a purpose the original author wouldn't have predicted,
maybe. Run-time assertions could check that the inputs have the
required characteristics, but those characteristics might not
be restricted to the simple notion of "type". (For example,
maybe it is better to allow any object which will _act_ as an
integer, rather than just integers. If only integers are to
be allowed, Python easily supports checking for this, at run-time.)
> I don't know if that means Python should have type checking. Its
> open typed design works awfully well with OOP, and it would be a
> shame to strangle that freedom for the sake of a half-baked concept
> of discipline. But some kind of type inference validation could be
> applied from a lint utility - that already exists and is reportedly
> useful, but I don't know if it actually covers types.
The problem with an external checking utility such as lint, or
the proposed division scanning utility, is that it only works
in a limited set of cases (although perhaps the majority of cases).
What it can't do is deal with some cases which are possible
because of the dynamic nature of Python. It may be only at
run-time that one can determine which inputs are actually being
fed to a subroutine, for example.
This is where testing comes in. A compiler can only check
whether you have followed the rules to which it restricts you.
Testing, however, can verify that, whether you followed the
rules or not, the code is doing what you think it should.
Testing is both necessary and sufficient for Python code.
With statically typed languages, testing is still necessary,
though probably done less often, while compile-time checking
is _not_ sufficient, yet that's all most people use.
In the end, whether or not Python suffers because of a
lack of compile-time checking is hardly the issue. Anyone
relying on such simplistic means to provide them with
confidence in their code's correct operation is deluding
themselves. Python just doesn't try to delude you: if
you want safe code, test.
> Anyway, maybe it's an area where a big investment could yield
> something real interesting for industrial strength programming.
I suppose you could say my group does "industrial strength"
programming with Python, since we're in industry :-) and the
strength of the code -- without compile-time type checking --
is quite adequate for now.
Of all our problems, well under 5% are related to problems
caused by Python's syntax, lack of compile-time type checking,
division behaviour, and other such things. Adding static types
(i.e. _requiring_ them) would cost us significant productivity
with next to no practical gain (since they would catch a small
fraction of less than 1% of our problems).
(Note: these numbers are anecdotal, unscientific, and made up.
Hah, some engineer! :-)
Peter Hansen, P.Eng.
peter at engcorp.com
More information about the Python-list