On Fri, Jan 23, 2015 at 7:59 PM, Stephen J. Turnbull <stephen@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 (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 referring to an old mypy wiki page 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) 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)