[Types-sig] Static typing considered HARD

[Paul Prescod]

I'm still not sure what to do about the static typing and the types sig.
The more I thought about types the less I became convinced that a quick
"low hanging fruit" approach would work. I no longer propose a quick RFC
on static typing.

Here's the problem: in Visual Basic, Java, ML  and other languages I am
most familiar with, compilation is conceptually three pass:

* parse
* "resolve names to type/code/variable references"
* execute

In other words, the entire universe of types is figured out before a
single line of code executes. In that context the words "static typing"
have an obvious meaning. While you are resolve name references you do a
bunch of checks to make sure that they are used consistently.

But in Python, type objects only come about *through* the execution of
code. This makes Python incredibly dynamic but it also means that the
question of what exactly static type checking means is confused. Simple
example:

import sys

if sys.argv[0]=="weirdness":
	from foo_mod import foo_class
else:
	from foo_mod2 import foo_class

One could imagine that in some Python 2, import statements and class
definitions could be limited to being at the top, before "code". There
might be some special syntax (e.g. __import__, __define_class__ ) for
doing module-loading and type definition at runtime. Still, I don't
consider that something for the types-sig to work out. My personal
opinion is that it would be a Good Thing for Python to become a tad less
dynamic in the "core syntax" in exchange for compile-time checking of
names.

Note that in a lot of ways, Java is "as dynamic" as Python. You can
introduce new functions and classes "at runtime." The difference is that
Java's syntax for doing so is brutally complex and verbose so you are
disinclined to do it. I think that there must be a middle ground where
our "default semantics" are static but it is easy enough to do dynamic
things (e.g. foo_mod = __import__( "foo.py")) that we don't feel
burdened.

Our innovation beyond Java would not just be syntax. We could recognize
that modules and types introduced "at runtime" are pyobjects and just
allow them to be used with no casting or special syntax. Only the
*introduction syntax* would be special. So where Java would say
something like:

this.that.Module mod = this.that.LoadModule( "foo" )
this.that.Class cls = mod.loadClass( "myclass" )
this.that.Method meth = cls.loadMethod( "doit" )
this.that.Arglist args = new ArgList()

args.addArg( "arg1" )
args.addArg( "arg2" )

Object rc = meth.Invoke( args )

Python would say something like:

foo = __import__( "foo" )
foo.myclass.doit( "arg1", "arg2" )

Once again, Visual Basic (shudder) is a good guide here. Although I am
not consciously cloning Visual Basic, my ideas seem to be naturally
tending towards it. Once again it seems to have a pretty common sense
(to me!) approach to static type checking.

Even if we ignore static type checking Python 2 really has to do
something about the "misspelling problem." One extra character on a
method name can crash a server that has been running for weeks. Once
this problem is fixed, the term "static type checking" will become
meaningful. In the current environment, it is probably not and thus
should not be the first focus of a new types-sig.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin