[Python-3000] Type annotations: annotating generators

[Guido van Rossum]

On 5/19/06, Paul Boddie <paul at boddie.org.uk> wrote:
> Guido van Rossum wrote:
> >
> > I'm not convinced that we need all this for the likely intended use,
> > since static type checking isn't really high on the agenda anyway.
>
> I know I'll get into trouble for quoting this out of context, and I accept
> that there's a difference between static typing and writing declarations that
> look like static type declarations but which operate at run-time. However, I
> keep wondering whether we're missing out on something by adopting a type
> description language that will either prove to be inadequately expressive or
> evolve to something on the level of a full programming language in its own
> right.

WhatI'm trying to do primarily is add just enough new syntax that
people can write their own such system. This is the optional ":
<expr>" after parameter names and "-> <expr>" after a function
heading.

The rest is just an exercise in attempting to come up with a pragmatic
set of operators and conventions that some people might be using for
talking about types. This is the idea of parameterizing types a la
dict[str, int|str] (which I should point out is valid *syntax* today
and can be made to execute correctly by modest additions to the type
metaclass) and solving various other issues pragmatically, e.g.
lambda:A for forward references and Funct(int, list[int]).returns(int)
to describe signatures.

> What's the general opinion on systems which attempt to infer and predict
> inappropriate type usage? (Which I'm guessing is the main motivation here,
> rather than performance, which if I recall correctly, was downplayed in the
> context of "optional" type declarations.) By "predict", I mean something that
> operates before run-time; not something which tells you 100ns before an
> exception is raised. Couldn't such systems be a better aid to program
> reliability? Would "optional" type declarations be relevant to the operation
> of such systems?

I expect that something like pychecker could be taught enough about a
set of conventions to be useful. I don't expect that it will make all
bugs apparent at compile time, but pragmatically, it should be able to
do very well (much better than today's pychecker).

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