[Python-3000] Misc type annotation issues (original) (raw)

Guido van Rossum guido at python.org
Sat May 20 18:29:47 CEST 2006

On 5/20/06, Collin Winter <collinw at gmail.com> wrote:

Some things I still have listed as "outstanding issues" for the annotations PEP:

1. You mentioned in one blog post [1] that you wanted to have 'any' and 'nothing' types. Is this still something you want as built-ins, or should it be left up to the annotation-interpreting libraries to provide these?

Since their semantics are up to the libraries they should also be defined there.

2. Do you still want syntactic support for super/subtyping? In [1], you mention using something like "T1 <= T2" to indicate that T1 is a_ _subtype of T2 and "T2 >= T1" to say T2 is a supertype of T1.

Lukewarm. If we have typecheck(x, T) (in the library or whereever) perhaps we could also have issubtype(T1, T2) there.

If you still want this syntax, what do these inequalities return? The obvious answer is "a boolean", but you go on to use something like "list[T <= Number]" to indicate a list of subtypes of Number. To me,_ _this latter example should be written "list[Number]", freeing <= and_ _>= on types to return booleans as expected.

That was probably an earlier wild idea where 'T' would automatically become a free (type) variable. Let's not go there for now.

However, since we're giving so much control to the annotation-interpreting libraries, trying to define a useful and consistent semantic for built-in super/subtyping inequalities would run into the same problem as would a built-in typecheck() function. Like typecheck(), it would be better to let the third-party libraries provide their own issubtype() and issupertype() functions.

Agreed.

3. What will annotations on *varargs and **varkw look like? My own suggestion is that

>>> def foo(a: , *varargs: , **varkw: ) is fully equivalent to -- and is indeed coerced to -- >>> def foo(a: , *varargs: list[], **varkw: dict[str, ]) What did you have in mind?

We can't allow both the shorthand and the full notation, since then there would be ambiguity: if "*args: int" meant the same as "*args: list[int]", then what if I want each of the remaining positional arguments to be a list of ints? "*args: list[int]" is already taken to mean that each of the remaining arguments is an int.

Since the full notation is unnecessarily verbose, I propose that "*args: T" means that each of the remaining arguments should be a T, and the type of args itself is list[T]. Similar for **kwds.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list