[Types-sig] RFC 0.1

[Paul Prescod]

I did evaluate your proposal but it seemed to me that it was solving a
slightly different problem. I think as we compare them we'll find that
your ideas were more oriented toward runtime safety checking.

Greg Stein wrote:
> 
> > > #2. The system must allow authors to make assertions about the sorts
> > > of values that may be bound to names. These are called binding
> > > assertions. They should behave as if an assertion statement was
> > > inserted after every assignment to that name program-wide.
> 
> In our writeup, we posit that it is better (and more Pythonic) to bind the
> assertions to expressions, rather than names. This came about when we
> looked at how to supply assertions for things like:
> 
>   x.y = value
>   x[i] = value
>   x[i:j] = value

I wouldn't supply assertions for assignments at all. You supply
assertions for the names x, y, i, and j.

> Certainly, function objects would have type information associated with
> them, but I believe that is different than associating a type with the
> function's name.

But if a function takes as its first argument an int, in what sense is
that type associated with an "expression"? It is associated with a name,
whatever the name of the first argument is. Plus consider this:

type-safe
String
def foo():
	return abc()

How can I, at compile time, statically know the type of the value
currently contained in the name abc if I don't restrict it in advance
like this:

String
def abc(): return "abc"

Rebinding is fine, as long as it doesn't invalidate the type
declaration:

abc = lambda: "def"

> We also proposed extending isinstance() to allow a callable for the third
> argument. This allows for arbitrarily complex type checking (e.g. the
> "list of integers" problem).

I liked that idea but really didn't see how to port it to a compile time
static type checker. I'm going out of my way to avoid running arbitrary
Python code. Static type checking shouldn't be a security hazard.

> [ side note: if we get replaceable parser/compiler functionality in 1.6,
>   then we can start to test these alternative grammers and can compile
>   assertions and things based on them! ]

That would be way cool!

> If type assertions are bound to expressions, rather than names, a data
> flow analysis will show the types at any point. This could (theoretically)
> avoid many "declarations".

Names get their values from expressions so the data flow analysis is the
same.

If you have to type-check the statement "return a" then you need to be
able to know the type of both the variable and the expression.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html