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

Stephen J. Turnbull stephen at xemacs.org
Sat Jan 24 04:59:15 CET 2015

Guido van Rossum writes:

 > > I think typing should have a make_stub(inpy, outstub) function to make
 > > blank stub creation easy. [...]
 > That sounds like a useful tool, but why should it be in typing.py?

It's an obvious place to look for it.  You could put it in the
checking application, but with multiple applications that would result
in code duplication, wouldn't it?

 > > 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.
 > On a par. Stubs are essential for extension modules, and nearly essential
 > for existing packages (both 3rd party and the stdlib!). But I don't want
 > people writing new 3.x code having to deal with two files for every module.

I think what Terry is suggesting is that if you want *both* type hints
and some other use of annotations, you could get that by putting the
type hints in a separate file, and that this should be documented.  I
agree the arguments for "encouraged" are weak (except in case where
multiple forms of annotation are desired), and the annoyance of the
C/C++ .c/.h partition is quite discouraging.

Note that, IIUC Terry's idea, this would also allow library authors
or users to disable type hinting warnings permanently with "touch
<stubfile>".  I think that's a reasonable burden, especially since it
only requires directory write access for the user to disable warnings
if they have a package using non-typing annotations.

Aside: I can't agree with those who think that many users of typing
should have to request type-checking *three* times: once by writing
the hint, once by running the checker, and once by importing typing.

More information about the Python-ideas mailing list