[Python-ideas] Proposal: Use mypy syntax for function annotations

Antoine Pitrou antoine at python.org
Wed Aug 13 23:12:26 CEST 2014


Hello,

First, as a disclaimer, I am currently working on Numba for Continuum 
Analytics.  Numba has its own type inference system which it applies to 
functions decorated with the @jit decorator. Due to Numba's objectives, 
the type inference system is heavily geared towards numerical computing, 
but it is conceptually (and a bit concretely) able to represent more 
generic information, such as "an enumerate() over an iterator of a 
complex128 numpy array".

There are two sides to type inference:

1) first the (optional) annotations
(I'm saying "optional" because in the most basic usage, a JIT compiler 
is normally able to defer compilation until the first function or method 
call, and to deduce input types from that)

2) second the inference engine properly, which walks the code (in 
whatever form the tool's developer has chosen: bytecode, AST, IR) and 
deduces types for any intermediate values

Now only #1 is implied by this PEP proposal, but it also sounds like we 
should take into account the desired properties of #2 (for example, 
being able to express "an iterator of three-tuples" can be important for 
a JIT compiler - or not, perhaps, depending on the JIT compiler :-)). 
What #2 wants to do will differ depending on the use case: e.g. a code 
checker may need less type granularity than a JIT compiler.


Therefore, regardless of mypy's typesystem's completeness and 
granularity, one requirement is for it to be easily extensible. By 
extensible I mean not only being able to define new type descriptions, 
but being able to do so for existing third-party libraries you don't 
want to modify.

I'm saying that because I'm looking at 
http://mypy-lang.org/tutorial.html#genericclasses , and it's not clear 
from this example whether the typing code has to be interwoven with the 
collection's implementation, or can be written as a separate code module 
entirely (*). Ideally both should probably be possible (in the same vein 
as being able to subclass an ABC, or register an existing class with 
it). This also includes being to type-declare functions and types from C 
extension modules.

In Numba, this would be typically required to write typing descriptions 
for Numpy arrays and functions; but also to derive descriptions for 
fixed-width integers, single-precision floats, etc. (this also means 
some form of subclassing for type descriptions themselves).

(*) (actually, I'm a bit worried when I see that "List[int]()" 
instantiates an actual list; calling a type description class should 
give you a parametered type description, not an object; the [] notation 
is in general not powerful enough if you want several type parameters, 
possibly keyword-only)


At some point, it will be even better if the typing system is powerful 
enough to remember properties of the *values* (for example not only "a 
string", but "a one-character string, or even "one of the 'Y', 'M', 'D' 
strings"). Think about type-checking / type-infering calls to the struct 
module.


I may come back with more comments once I've read the mypy docs and/or 
code in detail.

Regards

Antoine.




More information about the Python-ideas mailing list