[Types-sig] Proposed Goals PEP

[Paul Prescod]

I propose that the first round of the types-sig focus on a syntax for
type declarations in classes (and by extension interfaces). The goals of
type (recently expanded from three to four) annotations are error
checking (err), documentation (doc), optimization (opt) and glue to
static type systems (glue). In order to allow the resolution of
conflicts between goals I claim that we should treat their order of
importance as err, doc, opt and glue. 

In particular, there are many approaches to opt that would vastly
improve Python's performance but vastly degrade its dynamic features. We
should agree that Python's strength is that usability comes before
performance.

Here are the goals expanded:

1. Better error checking. (major)

If I call a C function with wrong arguments I get a very readable error
message:

>>> open(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: open, argument 1: expected string, int found

If I call a Python function in the standard library with wrong arguments
I get this:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "c:\python20\lib\urllib.py", line 139, in open
    fullurl = unwrap(fullurl)
  File "c:\python20\lib\urllib.py", line 857, in unwrap
    url = string.strip(url)
  File "c:\python20\lib\string.py", line 80, in strip
    return s.strip()
AttributeError: 'int' object has no attribute 'strip'

If there are many levels of code it is not at all clear where the value
first went "bad". We want to make it possible to detect the mistake much
earlier. 

The canonical "use case" for this is the standard library. The standard
library should check argument values for sanity as much as is is
practical. Right now it does not do much checking because the syntax for
doing so is obfuscatory and verbose.

2. Better Documentation (major)

Right now, it is basically impossible for programs like PyDoc or IDLE to
detect the types of arguments to functions. This makes it difficult to
give the user a clear summary of what a function expects or returns.

Use cases:

There should be enough information in Python code so that PyDoc could
look at the declaration for the "open" function and tell the usr that
the first argument must be a string and the second must be an integer.
There should be enough information to hyperlink from references to types
to definitions of those types.

3. Optimization (minor)

If a Python compiler knew that a function works on integers or strings
then it could internally use bytecode or native code optimized for
integers or strings.

4. Static type glue (minor)

There are a plethora of language-interopability technologies out there
and most of them use static type checking systems. Examples include
CORBA, COM, DCOM, XPCOM, RMI, .NET, SOAP/WSDL. It would be nice if
Python programmers could generate IDL/WSDL/type libraries etc. from type
annotations in their Python code. This is even useful in a simple
C+Python application. If there are places where C must call into Python,
we currently require type conversions to be handled manually. It would
be nice if we could use a "reverse SWIG" to generate a wrapper that
would make it easy to call Python code without manual type conversions.

Constraints:

In order to get something done in a reasonable amount of time we must
decide which issues not to tackle. At the top of that list, in my
opinion, is static type checking (including a formally defined type
inferencing system). Second is any form of higher order types. If we
could agree that these are NOT on the table we will make progress much
more quickly.

In general, a major constraint is that a type system for Python should
be simple. We should not be afraid to teach the type system to high
school students. If Python's type system makes anyone's brain explode
then we have not done a good job.

-- 
Python:
    Programming the way
    Guido
    indented it.
       - (originated with Skip Montanaro?)