[Types-sig] RFC 0.1

[Greg Stein]

My comments below come from a writeup that is posted at:
  http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html

The writeup is from a discussion last year, between Fred, Sjoerd, and
myself. I'm not going to replicate the details of that writeup here, but
will simply highlight some points. Hit the link to see the background.


On Mon, 13 Dec 1999, Guido van Rossum wrote:
> Paul Prescode 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

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.

> Technically, Python assert statements are only executed in
> non-optimizing mode -- "assert 0" has no effect when you happen to use
> "python -O" to execute your program.  But I presume that here you mean
> assertions in the abstract conceptual sense.

We proposed a new type-assertion operator. Whether it did anything or not
(based on the -O switch) is a different discussion :-)

>...
> > #9. There should be a mechanism to assert that an object has a
> > particular type for purposes of informing the static and dynamic type
> > checkers about something that the programmer knows about the flow of
> > the program.
> 
> Beyond "assert isinstance(object, type_or_class)" ?

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

>...
> > #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."
> 
> It's been said before: that's a shame.  Type inference is seriously
> hindered if it doesn't have such information.  (Consider a loop over
> sys.argv; I want the checker to be able to assume that the items are
> strings.)

The mechanism we outlined would allow any dotted-name for specifying a
type, and the "isinstance(ob, callable)" mechanism would allow for complex
type checking.

>...
> > #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.
> 
> I think that this is too much of a constraint, and may be informing
> your preliminary design too much.  As long as an easy mechanical
> transformation to valid Python 1.5.x is available, I'd be happy.

I believe we came up with an unambiguous grammer which should easily allow
for mechanical translation.

[ 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! ]

>...
> >     4. The classification of class instance variables comes from the
> > classification of the corresponding class variable. 
> > 
> > <example>
> > class foo:
> >     types.IntType
> >     a=5
> > 
> >     types.ListType
> >     b=None
> > </example>
> 
> The initialization for b denies its type declaration.  Do you really
> want to do this?  This doesn't look like it should be part of the
> final (Python 2.0) version -- it's just too ugly.  How am I going to
> explain this to a newbie with no programming *nor* Python experience?

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

> > Classification-testing expression:
> > 
> > The function has_type takes a value and a reference to a
> > classification or list of classifications. The return type of the
> > function is the union of the classifications.
> 
> Perhaps this could be an extension of isinstance()?  (That already
> takes both class and type objects.)

See my proposed extension to isinstance(). I believe it is a very clear
extension and offers all the functionality you may need.

Cheers,
-g

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