[Types-sig] Type annotations

[Paul Prescod]

Martijn Faassen wrote:
> 
> I disagree that it gets too hairy. I'm advocating using Python
> *precisely* because of the complex types. Python expressions can deal
> with that kind of complexity right now. What's all this obsession with
> syntax early on about anyway? It only distracts us from the real topic,
> in my opinion..

I see the situation this way:

Python has a type system. It works. (though there are some subtle
improvements coming) Our job is to define a syntax and semantics for
type assertions and also 
 a) the operation of a software processor called a "type checker"
 b) changes to the runtime behavior of the PVM to support the accuracy
of a)

I don't see us as being at that "early on" of a stage. In my head, at
least, the pieces are coming together nicely. At this point, I seem to
be in agreement on most non-syntactic issues with Tim, Greg and Guido so
I think that we are converging. I admit that I have not yet integrated
all of the ideas of you, Edward and a few other people. I don't have
time to read everyone else's work carefully and nobody has time to read
everyone else's either!

Maybe this email will help with that. It outlines what I see as the
consensus so that we can debate these things one last time and put them
behind us.

I don't have time to write up all of the semantics of the system yet but
the major parts are:

 * local variables types are usually inferred
 * module variables and instance variables may have type declarations
 * non-local writes are checked at runtime (by default)
 * for optimization, the checks may be stripped based on type inferenced
information
 * function return types are NEVER inferred
 * ...they must be declared or assumed to be PyObject
 * "types" can be Python primitive types, or declared classes or
interfaces
 * built-in types are declared through "shadow files"
 * but a function return statement could be verified based on
inferencing to conform to its declaration
 * expression assertions support within-function assertions
 * function parameters can have declarations
 * function calls and assignments are checked at runtime if they cannot
be verified at compile time
 * but you can ask for an explicit verification at compile time
 * which enables faster code to be generated
 * ...and verifies your understanding of what you are doing

 * types can be parameterized
 * which means that the compile/runtime checks need to be more
sophisticated

 * we do not yet handle the "exception interface" of a function
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things never trust in: That's the vendor's final bill
The promises your boss makes, and the customer's good will 
http://www.geezjan.org/humor/computers/threes.html