[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Terry Reedy]

On 1/22/2015 3:05 PM, Guido van Rossum wrote:


> Having got that off my mind, the vast majority of Python code that's
> been written does not use annotations at all, so there is no reason to
> change it at all. For code that does use annotation, *nothing* will
> break at run time -- the code will work unchanged, without any
> deprecations or slowdowns.
>
> The only situation where there may be a desire to change something (the
> minimal thing being to add a "# type: OFF" comment at the top of a
> module) is when a library that uses annotations for non-type-hinting
> purposes is used by an application (or another library) that wants to
> use type hints, and the user who is running the type checker cannot live
> with the noise output spewed by the type checker for that library.

I believe the dual-use of annotations problem would be solved if static 
type checkers gave precedence to annotations in stub files.  Putting 
type hints in separate files is *possible* because static checkers do 
not need and will not use a runtime .__annotations__ attribute.  If the 
presence of a stub file meant that annotations in the corresponding .py 
file were ignored by static checkers, then they could still be used in 
.py files to create .__annotations__ for dynamic use.

I think typing should have a make_stub(inpy, outstub) function to make 
blank stub creation easy.  It would copy all def headers and add ':' and 
'->' where appropriate.  It could have an any=??? option which, when 
true, would add 'any' everywhere.  Running typing as a script (-m) could 
run make_stub.  An all-any stub would eliminate the need even for 
#type:off, and could be added by a user without touching the .py file.

I think putting type hints in stub files should be documented as at 
least on a par, if not encouraged, with putting them in .py files.

1. As with writing tests, only a subset of python programmers will 
enjoy, be willing to, and be good at writing complex type hints.  So 
stub files might be writtin by someone other than the .py author(s).

2. In some cases, type hints intended to be as accurate as possible will 
not be pretty -- or simple.  In a separate file intended for machine 
consumption, aesthetics can more easily be ignored in favor of accuracy.

3. Users may want to add or customize annotations (perhaps to narrow the 
allowed arguments to conform to policy).  This is better done in a 
separate file.

-- 
Terry Jan Reedy