[Types-sig] consensus(?) summary (was: Type annotations)

Greg Stein gstein@lyra.org
Thu, 16 Dec 1999 13:16:20 -0800 (PST)

On Thu, 16 Dec 1999, Paul Prescod wrote:
> 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

Woo! :-)

>  * module variables and instance variables may have type declarations

Yes. I believe this is because these variables fall under the same rubric
of "interface declarations." One interface for the module, another for a

>  * non-local writes are checked at runtime (by default)

Hrm. Is there an easy rule to determine this? I might suggest deferring
this unless/until we have a clear set of rules. Shades of C++'s "friend"
modifier are forming in my head when we talk about this...

>  * for optimization, the checks may be stripped based on type inferenced
> information

Which checks? I think runtime checks are *ignored* if you run with -O.
Python doesn't (yet) have different forms of compilation (or did I miss
something?). Certainly, in 1.6 we can have different compilations by
virtue of substituting a new compiler, but I think it would be nice to
retain a single form of compilation.

In reference to type-inferred information: I don't think runtime checks
would ever be added if the type has been inferred.

Issue: what are the rules for inserting runtime checks? When are they
added and when are they not?

      1) they are added for function arguments which have type declarators
         (i.e. added as a function prologue).
      2) they are added when the type-assert operator is used.

>  * 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"

This is somewhat problematic. How do we map from a builtin type to this
shadow file? Do they reside in a well-known location?

Second issue: keeping them in sync, version mismatches, distribution and
install problems, etc.

My recommendation would be to enable a mechanism by which modules can
internally declare their interface. I recognize this is complex and would
therefore defer any discussion regarding interfaces for builtin types.

Note: and when I say "builtin type", I'm referring to things like "socket"
rather than the "core types" such as List or Dict.

>  * but a function return statement could be verified based on
> inferencing to conform to its declaration

Yes. This would be a compile-time static check.

>  * 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

Function calls: yes.

I'm not sure we would ever check assignments. See my response above,
regarding knowing when the proper time is. Instead, I think that an
interface is a statement (to users) about the types, but we don't
necessarily have to enforce it. Hrm. This kind of falls under the concept
of "verifying an implementation conforms to an interface." I would prefer
to avoid that.

>  * 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

I'm not clear on your points here.

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

Yes, although I might modify it somewhat and say "only core types can be

>  * we do not yet handle the "exception interface" of a function

Thank you :-)


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