<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 7:59 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Guido van Rossum writes:<br>
<br>
 > > I think typing should have a make_stub(inpy, outstub) function to make<br>
</span> > > blank stub creation easy. [...]<br>
<span class=""> ><br>
 > That sounds like a useful tool, but why should it be in typing.py?<br>
<br>
</span>It's an obvious place to look for it.  You could put it in the<br>
checking application, but with multiple applications that would result<br>
in code duplication, wouldn't it?<span class=""><br></span></blockquote><div><br></div><div>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.<br><br></div><div>FWIW, I just remembered that there is actually a really cool stub generator that's part of mypy: <a href="https://github.com/JukkaL/mypy/tree/master/pinfer">pinfer</a> (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 <a href="https://github.com/JukkaL/mypy/issues/43">old mypy issue</a> referring to an <a href="http://www.mypy-lang.org/wiki/StubGeneratorTool">old mypy wiki page</a> about stub generation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
 > > I think putting type hints in stub files should be documented as at least<br>
 > > on a par, if not encouraged, with putting them in .py files.<br>
 ><br>
 > On a par. Stubs are essential for extension modules, and nearly essential<br>
 > for existing packages (both 3rd party and the stdlib!). But I don't want<br>
 > people writing new 3.x code having to deal with two files for every module.<br>
<br>
</span>I think what Terry is suggesting is that if you want *both* type hints<br>
and some other use of annotations, you could get that by putting the<br>
type hints in a separate file, and that this should be documented.</blockquote><div><br></div><div>Yeah, as a transitional measure. Eventually other use of annotations will look weird to most people.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree the arguments for "encouraged" are weak (except in case where<br>
multiple forms of annotation are desired), and the annoyance of the<br>
C/C++ .c/.h partition is quite discouraging.<br>
<br>
Note that, IIUC Terry's idea, this would also allow library authors<br>
or users to disable type hinting warnings permanently with "touch<br>
<stubfile>".  I think that's a reasonable burden, especially since it<br>
only requires directory write access for the user to disable warnings<br>
if they have a package using non-typing annotations.<br></blockquote><div><br></div><div>But with the current concept of stub files (<a href="http://www.mypy-lang.org/wiki/CreatingStubsForPythonModules">borrowed from mypy</a>) 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.)<br><br></div><div>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:<br><br></div><div># type: OFF<br>def foo(a):<br></div><div>  return a+1<br><br></div><div>and in file b.py there is this:<br><br></div><div>from a import foo<br></div><div>foo(1, 2, 3)<br>foo('hello')<br><br></div><div>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.<br><br></div><div>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.)<br><br>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.<br><br>Or should we allow some special non-Python syntax in stub files to signal the same thing?<br><br></div><div>E.g.<br><br></div><div>* = * # type: Any<br><br></div><div>or<br><br></div><div>* = Undefined(Any)<br><br></div><div>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.<br><br></div><div>Sorry for the rambling post.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Aside: I can't agree with those who think that many users of typing<br>
should have to request type-checking *three* times: once by writing<br>
the hint, once by running the checker, and once by importing typing.<br>
</blockquote></div><br></div><div class="gmail_extra">Thanks. I doubt that's going to happen.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>