[Types-sig] Re: RFC 0.1

[Golden, Howard]

Paul Prescod 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.

I think the system should also allow the author to require declarations of
all variables (e.g., via a command-line switch or pragma).

> #3. Binding assertions must always be optional.

Unless the author requires them using the above mechanism.

> #10. In general, the mechanism should try to be "pythonic" which
> includes but is not limited to:

>   * maximize simplicity
>   * maximize power
>   * minimize syntax
>   * be explicit
>   * be readable
>   * interoperate nicely with other features

This is vague.  I'm not sure what it means.

> 1. The first version of the system will be as neutral as possible on
> the issue of what defines a "type". Fulton's capability-based
> interfaces should be legal as types but so should type objects and
> classes.

I don't understand the ramifications of this.  Might it not gut the RFC?

> Note: a purely interface based system cannot be feasible for testing
> until interfaces are embedded deeply into the existing Python library.
> It might be more philisophically pure to test for an abstract
> CharacterString interface but if the Python expression "abc" does not
> return an object that conforms to the interface then there is not much
> we can do. Some future version of the system may be restricted to only
> allow declared interfaces as types. Or it may be expanded to allow
> parameterized types.

Shouldn't it be straightforward to add declarations to the existing library?

> #2. The first version of the system will not allow the use of types
> that cannot be referred to as simple Python objects. In particular it
> will not allow users to refer to things like "List of Integers" and
> "Functions taking Integers as arguments and returning strings."

Why?  I don't think this should be prohibited, only not guaranteed.

> #4. The first version of the system will be syntactically compatible
> with Python 1.5.x in order to allow experimentation in the lead-up to
> an integrated system in Python 2.

Does this mean no new syntax?  (That's what it appears from your examples.)

How about a declaration syntax, e.g.,

    var x : type1, y : type2

Is this prohibited by the RFC?

>    Definitions:
>    ------------

I'm confused about this section.  Are these requirements or merely
terminology?

In general, I don't understand the definitions.  It would help me if there
were some additional explanation of how the defined terms fit together and
what benefits are being obtained by making these distinctions.

---

Howard B. Golden
Software developer
Litton Industries, Inc.
Woodland Hills, California