[Python-3000] Type annotations: annotating generators

[Tony Lownds]

On May 19, 2006, at 9:14 AM, Paul Boddie 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.
>
> 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've been hacking on such a system, called "t_types". It is in pre- 
release form right now.
It actually deduces type usage using bytecode simulation, before run- 
time.

For t_types, starting the simulation with types more specific than  
"anything" is important
for reasonable results. In general I think optional type declarations  
are relevant to such
systems, whether a special syntax is adopted or decorators are used.

The proposals I've seen here for type annotation syntax seem very  
intentionally
designed NOT to lock in any particular type system. So far nothing  
seems to preclude
static type checking, at least the way t_types works. I hope the type  
annotation syntax
for functions goes in, it's a lot more readable than decorators.

Here's an idea of the flavor of type checking t_types gives.

from t_types import t

@t.signature(t.int|t.None, returns=t.int)
def test43(foo=None):
   if None is 1:
     # should be dead code
     return ''
   if 1 is None:
     # should be dead code
     return ''
   if foo is None:
     return 1
   else:
     # foo should have type of t.int here
     return foo

@t.signature(returns=t.list[t.int])
def test26():
   x = []
   x[0] = 1
   return x


Question for Guido/Collin:

Out of curiosity, are there concrete plans for how the type  
annotation syntax for functions
translates into bytecode?

Thanks
-Tony