[Python-ideas] PEP 484 (Type Hints) -- first draft round
tjreedy at udel.edu
Fri Jan 23 05:45:57 CET 2015
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
Terry Jan Reedy
More information about the Python-ideas