Adding static typing to Python

[Terry Reedy]

"Peter Milliken" <peter.milliken at gtech.com> wrote in message
news:a4ss56$akj6 at news1.gtech.com...
> Strongly typed languages encourage you to override the base types so
that
> you aren't forced one day (as an example) to go through all of the
source
> looking for places where floats are used and change them to double
floats -
> happened on one rather large project I worked :-) They changed the
compiler
> and it defined float as being 32-bit, the previous version defined
float as
> 64-bit - caused no end of heartache as you can imagine :-)

To me, this says that the 'strong typing' of C is a bit of a fraud!
To paraphrase:
Strongly typed languages encourage you to override the base types
because the base types are only loosely defined, so that you cannot
know what actual types they will translate into unless you specify the
machine, compiler, and version.

Python's int and float types are such overridings as you recommend.
They are usually the same as the int32 and float64 typedefs that many
C programmers use (and are guaranteed to be no smaller in any standard
implementation).  If your large project had used Python, it would not
have had that particular heartache.

The ongoing int/long unification will eliminate some current problems
even further by autoswitching base type as needed.  What
strongly-typed-language compiler will do that for you?  I believe such
behaviour violates the usual notion of 'strongly-typed'.  Does that
make it bad?

> So type'ing encourages things like defining data types that
encompass the
> range of values your variable is *expected* to have at the time you
> design/write your code i.e. you might be talking the temperature of
water -
> 0 - 100 Degrees Celsuis for instance.

Strictly speaking, these exact limits only apply to pure water in a
clean vessel bounded above by clean air at exactly standard pressure
and measure by an exactly accurate thermometer.  Even so, I believe
one can, with care, bring the water into a (temporary, unstable)
supercooled state below 0.0C.  Hard-coding ideal expectations into
types can make one's code unnecessarily brittle.

> Languages that are strongly typed like
> this then allow static checking at compile time i.e. the compiler
will tell
> you if you attempt to add a variable declared as Litres to a
Variable
> declared to hold Degrees Celsius.

The same compiler will probably

wrongly reject   2 * 3Liters (= 6 Liters),
wrongly accept  2Liters * 3Liters (= 6 Liters**2, not 6 Liters),
wrongly reject   2LitersperHour * 3Hours (= 6 Liters),

and similarly for division, so such a compiler is worse than useless
unless you restrict yourself to +- operations.  Do you know of any
compiler for any general-purpose language that correctly handles
measurement unit arithmetic out of the box?

One can write a class (or base class and set of classes) in Python
that will do so *correctly*, and I believe there is at least one such
module available.  Such can probably be done more efficiently that
before in 2.2 by deriving from float.

> Similarly, the compiler will complain if you attempt to assign a
temperature of
> 101 Degrees to a variable declared  with the above limits.

"Var = contstant"  is trivial to check, but *most* assignments are of
values not known until runtime.  How about

ta, tb = input("Enter two temperatures: ") # suppose user enters 70,80
tc = ta + tb # should this be rejected as illegal?
tc = tc/2.0 # maybe not
td = (ta + tb) /2.0 # should give 75 even though intermediate 150 is
'illegal'

Will your unnamed compiler generate the *proper* runtime checks?
Should they be at the point of computation, at the point of
assignment, or perhaps the end of a series of computations and
assignments?  Will the compiler generatethe same as what the
programmer considers proper?  Does the programmer get to catch an
'error' or does the program just stop?

> Ada allows run-time checking as well, so if you
> somehow manage to write code that passes the static checking

'somehow manage'?  as if writing 'tc = ta + tb' is difficult?

>it will blow up at run-time with a nice exception and traceback
> that tells you exactly what  and where it all happened :-)

As will raising an exception within a method of a Python class derived
from int or float.

Summary of my comments above:  Static typing only solves a small part
of the programming problem (and possibly less than its advocates
think).  It correctly rejects some incorrect code and enables more
efficient object code, but at the cost of writing more code,
incorrectly rejecting some correct code (hence coercion as a partial
solution), and giving a patina of correctness to some incorrect code.

Another point:  Static typing works against generic programming, which
to me is part of the essence of Python.  The unions and untyped (!)
preprocessor function definitions [as in "#define max(x,y) (x<y?y:x)"]
of C and templates of C++ are attempts to work around this clash.

Terry J. Reedy