[Python-3000] Misc type annotation issues

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: <type>, *varargs: <type>, **varkw: <type>)
>
> is fully equivalent to -- and is indeed coerced to --
>
> >>> def foo(a: <type>, *varargs: list[<type>], **varkw: dict[str, <type>])
>
> 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