[Types-sig] Progress

[Paul Prescod]

We are actually making progress among all of the sound and fury here.
You guys have a lot of good ideas and I think that we are converging
more than it seems.

1. Most people seem to agree with the idea that shadow files allow us a
nice way to separate type assertions out so that their syntax can vary.
I think Greg disagreed but perhaps not violently enough to argue about
it. Interface files are in. Inline syntax is temporarily out. Syntactic
"details" to be worked out.

2. Everybody but me is comfortable with defining
genericity/templating/parameterization only for built-in types for now.
But now that we are separating interfaces from implementations I am
thinking that I may be able to think more clearly about
parameterizability. It may be possible to define parameterizable
interfaces by IPC8. Parameterization is in. Syntactic "details" to be
worked out.

3. We agree that we need a syntax for asserting the types of expressions
at runtime. Greg proposes ! but says he is flexible on the issue. The
original RFC spelled this as:  has_type( foo, types.StringType ) which
returns (in this case) a string or NULL. This strikes me as more
flexible than ! because you can use it in an assertion but you don't
have to. You can also use it like this:

j=has_type( foo, types.StringType ) or has_type( foo, types.ListType ):

4. The Python misfeature that modules are externally writable by default
is gone. Only Guido has expressed an opinion on whether they should be
writeable at all. His opinion is no. Unless I hear otherwise, externally
writable modules are gone. (I have this vague feeling that maybe we
should think of modules as classes with methods and properties that
happen to be a subtype of a new base class "module", in that case the
rules for modules and classes should be identical)

5. It isn't clear WHAT we can specify in "PyDL" interface files. Clearly
we can define function, class/interface and method interfaces.

	a. do we allow declarations for the type of non-method instance
variables?

	b. do we check assignments to class and module attributes from other
modules at runtime? We need to expect that some cross-module assignments
will come from modules that are not statically type checked.

	c. should we perhaps just disallow writing to "declared" attributes
from other modules?

	d. is it possible to write to UN-declared attributes from other
modules? And what are the type safety implications of doing so?

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