[Types-sig] Re: RFC 0.1

[Paul Prescod]

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

I think that's a good idea for a particular implementation but I'm not
going to put it in the type system specification. If I were Guido I
would be unwilling to instruct every standard library package maintainer
to supply all type declarations in order to please the minority who want
to use Python in a manner that is as restrictive as Java.

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

I don't think so (yet). The main point is that we need to support
"types", "classes" and the new "interfaces"

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

Not just declarations: someone needs to actually define the set of
"standard interfaces." There are probably a few weeks worth of work
there and even a few weeks of work are hard to find since we all have
other jobs.

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

How can we allow it without defining the syntax? 

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

Yes, but I may change my mind on this issue based on Guido's feedback.

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

The definitions turned into the spec. The long and short of it is that
you can declare the types of variables:

StringType
a = "abc"

and functions:

StringType
def a(): return "abc"

and you can state that you want a function to be statically type
checked:

StringType
def a(): return "abc"

The spec is complex because I have to restrict the set of circumstances
where this "works" to things that can be detected statically. I
explicitly do not support stuff like this:

import somefunction
import a
import b

if somefunction.doit():
	mod=a
else:
	mod=b

a.SomeType
foo1 = None

b.SomeType
foo2 = None

mod
func( arg ):
	return a #valid or not??

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