[Types-sig] expression-based type assertions

[Greg Stein]

On Tue, 14 Dec 1999, Jeremy Hylton wrote:
>...
> Perhaps we need a charter revision.  We need to formally define a type
> system for Python.  It may or may not be statically checkable --
> that's just the way type systems work, e.g. Java does array bounds

In deference to Paul, I think it must be statically checkable. However,
your point about "completely checkable" is quite valid! We can have "as
much as possible" but not necessarily "completely."

Due to complex type issues, it may not ever be possible to be complete.
The question really becomes "how close?"

(note that expression-based type assertions allow a person to make
assertions on sub-components of a complex/composite type while it is being
used; this gives expr-based the capability to fill in where name-based
falls down because of a lack of syntactic expressability)

>...
> to check it).  The point of this digression is to argue that saying
> you only do "compile-time" checks is a bit of a cop out.

Damn... :-)

Personally, I in the (OPT) camp, rather than (ERR) camp, so I don't care
about static checks. But: the GFS proposal still supports it.

>...
>   GS> And to reiterate a point from my last note: I believe checks
>   GS> associated with shoving a value into a name are not as
>   GS> interesting, as 99% of the errors will occur at code boundaries
>   GS> (function calls), which are handled by the above mechanism.
> 
>   GS> In fact, I would even say that the only type declarations used
>   GS> would be associated with function params and returns (and not
>   GS> variable). If you are implementing a function and want to ensure
>   GS> that a result has a proper type, then the '!' operator can be
>   GS> used (shoving it into a typed variable isn't going to help
>   GS> you!).
> 
> I think I agree with you as far as local variables.  It becomes quite
> interesting when you're talking about attributes of objects, e.g. what
> is the type of the closed attribute of a builtin file object.  (For
> that matter, what is the type of the builtin open function and how
> does it differ from a function that returns a StringIO object?)

Ah! Good point. I think this is where interfaces come in. Otherwise, it
becomes very difficult to syntactically specify the types of attributes.
Note that many of the problems with type decls for builtin types would
probably be solved with interfaces, too. Until interfaces arrive,
Martijn's proposal of using structures to specify an interface is probably
best. A class or type can have an associated structure to specify
attribute type information (functions still use syntactical declarators).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/