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

[Paul Prescod]

> 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. 
 * presume that the type/class dichotomy has been removed in V2
 * backwards compatibility with current code is relatively important
 * compatibility with the Python 1.x interpreter is NOT important
 * interfaces are not an issue
 * parameterized (template) types are not available
 * names are type checked, not expressions
 * got now, only named types (types and classes) can be declared, not
lists and tuples of types

(many of these restrictions are easy to work around in Python: for
instance making a list of string subclass of userlist)

Start from these (very similar!) proposals:

http://www.python.org/~rmasse/papers/python-types/
The current Visual Basic type system
Something somewhere from JimH
The type declaration part of strongtalk
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.
Ideally, it should work much like the docstring discussion going on in
the doc-sig.

If we had a particularly ambitious editor (unlikely) then we could have
an RFC by the Python conference.

Later, we could do the same thing for the class/type dichotomy.
...then interfaces
...then parameterized types.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin