[Python-3000] Questions on optional type annotations

[Collin Winter]

On 5/11/06, Guido van Rossum <guido at python.org> wrote:
> Well, remember that the default use of type annotations is to ignore
> them! You can write your own decorator that implements a specific
> interpretation of the annotations, and you can make it do anything you
> like.
>
> I think it would be useful to have a notation that can express
> signatures. I haven't spent much time thinking about what this would
> look like, but I'd like it to require no new syntax beyond the concept
> of type annotations. If this means you can't have the inline
> equivalent of your (int int -> int), then perhaps it could be done by
> referencing some prototype with the appropriate annotations. Or
> perhaps someting as crude as Function(type, type, ..., returns=type)
> would be good enough for inlining this.

This exact thing (Function(type, type, ..., returns=type)) has been
kicked around for inclusion in typecheck. One problem with using a
keyword arg to indicate the return type means that functions passed in
can't use that keyword argument themselves (unless you're not going to
allow Function(arg1=type, arg2=type, ...)-style type annotations).

One solution to this might be that you can't use Function inline,
using an attribute to declare the return type (which should default to
None). This lends itself to solving the next issue...

> Regarding the question what to do if something un-annotated is passed,
> you could have a strict and a lenient mode, sort of the equivalents of
> guilty-unless-proven-innocent and innocent-unless-proven-guilty. I
> guess the latter is more Pythonic, but the former is more in style
> with type checking systems... :-)

Maybe we could let the user decide which mode to use. If we use an
attribute to declare the return type, we could use another to indicate
whether they want this particular Function() instance to be strict or
lenient.

If some form of type annotations is introduced in 2.x, we could then
observe which strictness option people prefer and make that the
default in Python 3000. Of course, the question still remains what
mode 2.x should default to.

Collin Winter