Python is DOOMED! Again!

[Steven D'Aprano]

Sturla Molden wrote:

> Python will no longer be dynamic, it will just be a slow static language.

It is worth explaining why this is wrong.

First, we need some definitions.

A *statically typed language* is one where variables have a type known to
the compiler at compile-time. That may be because the programmer declares
the type like in C:

    int n = 23;

or because the compiler can logically derive the type, like in Haskell:

    n = 23

(the compiler knows that 23 is an int, not a string or a Widget or a list,
and therefore on the assumption that you know what you are doing, n must be
an int too). Later, when you go to do an operation on n:

    n.append('foo')

the compiler knows that this must be an error, because n is an int, and ints
don't have an append method. And when you go to do an assignment:

    n = 'foo'

the compiler will prevent it because n is an int variable, not a string
variable.


In *dynamically typed languages*, variables don't have types, but *values*
do. Since variables don't have types, the compiler won't prevent you from
re-assigning a string to the same name that once held an int:

    n = 23
    n = 'foo'

but nor can it tell at compile time that n is an int and doesn't have an
append method. The way it tells is to wait until runtime and then attempt
to call the append method and see if it fails.

But... that's not a law of physics. Just because dumb compilers are dumb
doesn't mean that you can't have smarter compiles. 30 years ago the state
of the art for dynamic languages like Lisp and Smalltalk was good enough to
reason about type errors just as well as we human beings can. If we see:

    n = 23
    n.append('foo')

we know that this is going to fail. We don't need to run the code because we
can reason that at the time n.append is called, n is bound to an int and
ints don't have append methods. That's not very hard. Even Barry the intern
can do that, why can't Python?

Why can't Python tell me that 1+"1" will fail ahead of time?

Even in languages like C, the type-checking is done during a separate phase
of compilation, before code generation. So we can split the code-checker
out from the compiler, and make it a separate program which analyses the
source code, and stick it in your editor or IDE. Now when you start to
type:

   L = []
   L.appe

the IDE can guess that L is a list, and offer to auto-complete "append". But
given

   n.appe

it can predict that n isn't a list, and flag the word in red or beep or
something, depending on how annoying it wants to be. Or you can run the
type-checker as a separate program, like a linter or PEP-8 checker, and it
will analyse the source code and point out that on page 2 you assign n=23
and then on page 4 you call n.append but nowhere in the intermediate code
was n reassigned to a list.

If this was Java, the compiler would refuse to generate code while there are
any compile-time errors. But this is Python, and the type-checker is a
separate tool, so you can ignore it and run your script and sure enough you
will get an AttributeError when it tries to call n.append. Because maybe
you wanted an AttributeError.

This doesn't remove the dynamicism from the language. It's still dynamically
typed, it still has powerful runtime features. You won't even have to
declare types for everything if you don't want to.



-- 
Steven