[Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it.

[Martijn Faassen]

Paul Prescod wrote:
> 
> > taking-no-more-from-this-than-that-a-successful-sig-needs-a-
> >     focused-charter-ly y'rs  - tim
> 
> I propose that the types sig be re-commissioned with a much tighter
> commission. Let's focus on ONE of the three problems listed in our old
> charter:
> 
> http://www.python.org/sigs/types-sig/
> 
> And let's start with a clear direction from the Powers that Be.
> 
> I propose:
> 
>  * the goal is a optional static type system for version 2.

Okay, I'll assume this goal for now. I'd like to see something happen
with interfaces too, but I'll just assume/hope that an interface
proposal will arise 'naturally' from any static type system we come up
with.

>  * presume that the type/class dichotomy has been removed in V2

Gladly. So, what does this mean in practice? A particular class is
another
type? I don't want to accidentally start the discussion on the dichotomy
itself
here, I just want to know what Python 2 is like in practice. For now
I'll
assume that if I declare a class in Python 2, that class becomes a type.

>  * backwards compatibility with current code is relatively important

All right, though you'll run into trouble with any current code that
messes
too much with types, so we can just forget about that trouble, as it'd
be caused by the solving of the class/type dichotomy in any case.

>  * compatibility with the Python 1.x interpreter is NOT important

So we don't care if we can add static typing to the Python 1.x
interpreter line?

>  * interfaces are not an issue

Presumably they'll arise naturally, as I said before. :)

>  * parameterized (template) types are not available

Darn! I like these, if I understand what you mean. Don't we need things
like 'a list of integers'? Or 'a list of objects that have class-type
Foo' (objects of class Bar may be of class-type Foo too if Foo derives
from Bar).

If you want to actually use static types for compilation 'Swallow style'
(only compile those functions/classes that are *fully* static type
described) you'd need something like parameterized types..

Also, if you don't have parameterized types, you'll effectively lose
track (statically) of the type of any object once you put it in a list.

>  * names are type checked, not expressions

What does this mean? 

a = 4 @ IntegerType
b = a @ IntegerType # checked if a is indeed integertype
b = a + a @ IntegerType # not checked, as a + a is an expression

class Foo:
   def doFoo():
       print "Foo!"

a = Foo() @ FooType
a.doFoo() # does this do a typecheck for a? 

>  * got now, only named types (types and classes) can be declared, not
> lists and tuples of types

That fits in with the no template types idea, right?
 
> (many of these restrictions are easy to work around in Python: for
> instance making a list of string subclass of userlist)

Hm. But tuples, lists and dictionaries are very basic in Python. If the
types system does not support them that would seem to be a bit
incongruous (and inconvenient).
 
> Start from these (very similar!) proposals:
> 
> http://www.python.org/~rmasse/papers/python-types/

This does talk about interfaces (protocols) though. What part of this
proposal do you mean?

> The current Visual Basic type system

I'll reread your posts on that.

> Something somewhere from JimH
> The type declaration part of strongtalk

Any references?

> The first half of this:
> http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html
> 
> We should appoint an "editor" as they do in standards bodies. If there
> are issues that just cannot be worked out by consensus, Guido rules.

Guido would rule in any case if Guido disagrees with consensus, right?
:)

Regards,

Martijn