<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 16, 2018 at 2:56 PM, Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As one of the authors of PEP 484, *I* never thought there was an ambiguity here. The intention was for stub files to conform to the same grammar as regular .py files, but with a different interpretation.</div></div><div dir="ltr"><div><br></div><div>> "Have the same syntax as regular Python modules" and "are files containing type hints" are at odds with each other.<br></div><div><br></div></div><div dir="ltr"><div>That depends. *same syntax as regular Python* is normative while *containing type hints* is an informal description of intent.</div><div><br></div><div>I happen to be somewhat familiar with the situation that lead to this question -- pytype has its own parser for stub files that cannot parse all Python constructs. But claiming that PEP 484 is ambiguous feels wrong, and if we really need to clarify it the only way to go is to make "same syntax as regular Python" more clearly normative. Type checkers should of course feel free ignore everything they don't care about.<br></div></div></blockquote><div><br></div></span><div>I feel like the "same syntax as regular Python" is too broad a statement.  That effectively requires a version specific Python interpreter to execute the files.  With at least four different Python static analyzers in existence today, keeping the behavior of all of them consistent is important.  Otherwise pyi files will be (are being) created that are analyzer specific and break other type checkers when distributed.</div></div></div></blockquote><div><br></div><div>it doesn't require an interpreter, just a parser. Is saying it should be syntactically valid Python 3.6 (though emphatically not executable!) still too much?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>ex: We're encountering pyi files with conditional logic in them.  I believe we've encountered pyi files with del statements in them?  Both of these are a slippery slope towards being turing complete in something that isn't supposed to be code.  I don't like this.  Interface declarations should not contain logic.  If we allow conditions, we need to explicitly define what we do allow in the PEP.  (if+else and del?  what inputs are allowed for the expression in if statements?).  Otherwise at some point someone is going to create a pyi file containing loops, function calls, and generator expressions and expect it to _do_ something.  The horror!  Lets avoid that.</div></div></div></blockquote><div><br></div><div>Syntactically, conditional logic *is* part of the spec because of `sys.version_info` and `sys.platform` checks. These are mentioned in PEP 484 (though IIRC they were added at some point).</div><div><br></div><div>Feel free to ignore `del` statements, but they are valid syntax.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>PEP-484 does contain the text, "This also reinforces the notion that no runtime behavior should be expected of stub files." But reinforcing a notion is not what I read as a concrete statement.</div><div><br></div><div>I'd rather see that say something like, "There must not be any runtime behavior from a stub file. They will be parsed for information, not executed."  Wordsmith that all you want, I'm not pedantic enough. :)</div></div></div></blockquote><div><br></div><div>I don't see that as any more precise as what the PEP says. :-)</div><div><br></div><div>I'd be happy to claim that if the ast module can't parse a .pyi file, it's invalid, otherwise it's valid, except that `# type:` comments are significant and the ast module doesn't preserve those.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I expect someone pedantic to happily point out that a def or class or assignment to ... with an annotation is runtime behavior... technically correct, but that isn't how people like me think of them in this context.</div></div></div></blockquote><div><br></div><div>And mypy agrees. :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>We use a Pythonic syntax for stubs to be consistent with the language, that doesn't mean they are code.</div></div></div></blockquote><div><br></div><div>Define "code". To some people HTML is code.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I wrote more than I thought I would here, I'll stop now. :)</div></div></div></blockquote><div><br></div><div>It would be nice if the pytype team could articulate the problems they're trying to solve, rather than offering to "help finalize PEP 484". My guess is that their parser for .pyi files only accepts a subset of Python and they're (you're? do you report to Adam?) reluctant to sink more time in that parser -- but I don't think that's my problem. :-)</div><div><br></div><div>My intention for stubs was exactly what I've been saying in this thread: they must be syntactically valid Python, they are not meant to be executed, and type checkers are free to ignore things they don't need. If that's not sufficiently clear in the way the PEP is currently written, I welcome a PR to the peps repo. If the pytype team wants a different interpretation, the bar is much higher.<br clear="all"></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>