[Types-sig] Why I don't like static types in Python

[Tim Peters]

[Gordon McMillan]
> ...
> Jim Hugunin used global program analysis to demonstrate
> (admittedly contrived examples of) JPythonc compiled code
> running 2000X faster than CPython.  In the example, his
> analysis was able to arrive at the conclusion that a Python
> Int could actually be compiled to the Java for a native int.

FYI, at work we've seen Java recodings of our core computational kernels
reach 80% of optimized C++ speed, using a now somewhat out-of-date version
of Symantec's JIT.  That isn't fast enough, and neither is optimized C++
(our actual kernels are hand-tweaked assembler), but it is a sign of the way
things are going.

[Justus Pendleton]
> ...
> I have a question (since I don't know), if the static typing is
> voluntary then does that mean that nothing in the core python
> library could use static typing?

Of course not.  If e.g. all-integer lists ran 100x faster, you might see an
IntList.py added to the core, and maybe you'd be required to use static
typing *if* you wanted to use that module.  There are no consequence-free
changes.

[Gordon]
> ...
> It's also quite clear that static typing can prevent a kind of error
> that is very difficult to prove absent in a dynamic system. Whether
> it's worthwhile is another question, and one that really isn't
> answered for Python by looking at other languages.

I don't much care about Python's speed myself, and have been known to let a
Python program run non-stop for weeks.  It is the mother of all bitches,
though, when at the end of the month it dies with an AttributeError because
I typed:

    x.printReslut()

instead of

    x.printResult()

at the end.  So I try not to do that <snort>.  For some kinds of programs, I
would be happy to declare, define, delimit and constrain every name in my
program in triplicate, in return for a guarantee stuff like that wouldn't
happen at runtime.

> Unfortunately, it looks like the type / class thing can't be
> resolved until Python 2.

Unfortunate indeed!  That's the most important issue on this SIG's table.

> But I'd be surprised if anyone asked for empirical evidence that
> this is a flaw in the language.

I wouldn't <wink>.

throw-in-some-empirical-evidence-that-programming-
    of-any-kind-makes-the-world-better-and-back-it-
    up-with-a-double-blind-experiment-ly y'rs  - tim