PEP 3107 and stronger typing (note: probably a newbie question)

Terry Reedy tjreedy at
Thu Jun 21 05:22:49 CEST 2007

"Stephen R Laniel" <steve at> wrote in message 
news:20070620185337.GA22299 at
|| Reading [1], I wonder: why isn't the compiler making better
| use of (purely optional) type labeling? Why not make a compiler
| directive so that
| a) it will check the types of all my arguments and return
|   values, and maybe even
| b) do some type inference up the call stack?
| E.g.,
| def( Class1 arg1, Class2 arg2, ..., ClassN argN ):
|    someStuff()
| would check the types of the arguments, whereas
| def( arg1, arg2, ..., argN):
|    someStuff()
| would not? I.e., if I *want* strong static
| type-checking, why shouldn't I be able to get it?

1. Type checking arguments at compile time requires that the types of 
arguments be known at compile time.  Since arguments often are either names 
or expressions using names, this would require that names be typed and that 
all assigments to names be type-checked.  In other words, static typing 
pretty much all the way.

2. Python has multiple implementations.  Any requirement such as this would 
be a requirement on all.  It is possible that there will be some 
implementation that does something of what you want while the others 
continue as they are.  Or that there will be third-party add-ons (like 
psyco today).

3. There are multiple possible uses of type annotations: documentation, 
speed, error checking, and maybe others yet to be thought of.  Mandating 
any particular use would be a burden to anyone only interested in other 

As an old-timer, I also do not initially see the point of annotation with 
no (required) effect.  But then I realized point 3 above.

I believe that the statement you interpreted as 'forbidding' static typing 
was Guido's promise that annotations will *not* be a step towards turning 
Python into something else -- a staticly typed language.  That is important 
to the many people who use Python *because* it is dynamically and not 
statically typed and who consider that a net benefit.

Terry Jan Reedy

More information about the Python-list mailing list