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

[Guido van Rossum]

On Fri, Jan 23, 2015 at 7:59 PM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> 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?
>

Hm. It sounds like a kitchen sink or grab bag approach. Nothing else in
typing.py has even the remotest use for I/O or text processing. It would be
a whole bunch of code that would have nothing in common with the rest of
the stuff in typing.py except the name. If we wanted a calculator app,
should it live in math? Or perhaps in decimal? I don't think so.

FWIW, I just remembered that there is actually a really cool stub generator
that's part of mypy: pinfer
<https://github.com/JukkaL/mypy/tree/master/pinfer> (written or at least
greatly improved by Dropbox intern Jared Pochtar last summer). It runs your
program (typically a unittest suite) and through introspection discovers
the argument types of all methods that are called. There's also an old mypy
issue <https://github.com/JukkaL/mypy/issues/43> referring to an old mypy
wiki page <http://www.mypy-lang.org/wiki/StubGeneratorTool> about stub
generation.


>  > > 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.


Yeah, as a transitional measure. Eventually other use of annotations will
look weird to most people.


> 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.
>

But with the current concept of stub files (borrowed from mypy
<http://www.mypy-lang.org/wiki/CreatingStubsForPythonModules>) an empty
stub file is not enough. The functions and classes defined in the stub tell
the type checker what can be imported from the corresponding real module. I
think it would be simpler to have some other, out-of-band way to signal
that a module is off-limits. (I've proposed a configuration setting or
command line flag to the checker.)

This reminds me -- if you have a "# type: OFF" comment at the top of a
module, I presume the type checker still reads the rest of the file (at the
very least looking for "# type: ON"), and it may still record the presence
of things defined there, for the benefit of checking that things imported
*from* that module at least exist. The way I envisioned "# type: OFF" was
that the type checker will ignore annotations, essentially assuming that
annotations it sees don't exist. But when it sees the following in file
a.py:

# type: OFF
def foo(a):
  return a+1

and in file b.py there is this:

from a import foo
foo(1, 2, 3)
foo('hello')

It might still complain about the foo(1, 2, 3) call in b.py, because it
still knows that a.foo() takes exactly one argument.

My assumption so far has been that # type: OFF tells the checker that it
should not interpret annotations, because they may be used for other
purposes. (This has been the main reason for proposing # type: OFF.)

But maybe we want it to shut up more completely? Maybe there should be a
way to tell it that the entire *module object* for a has type Any, so that
*all* operations on it are allowed (and return Any)? An empty stub doesn't
do that -- but a config option like I proposed above could.

Or should we allow some special non-Python syntax in stub files to signal
the same thing?

E.g.

* = * # type: Any

or

* = Undefined(Any)

It might not be hard to teach a type checker (or other stub parser) about
such a magic pattern (if there was exactly one form), and instead of touch
a.pyi we could use 'echo "* = Undefined(Any)" >a.pyi.

Sorry for the rambling post.


> 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.
>

Thanks. I doubt that's going to happen.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150123/755b7155/attachment-0001.html>