<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 16.07.2018 19:21, Adam Cataldo via
Python-Dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKTwdc7+pdq_=QKD0hewtGQi6jPXBxtdr-A-tGmN7HMt_0xPCA@mail.gmail.com">
<div dir="ltr"><b style="font-weight:normal"
id="gmail-docs-internal-guid-88ce2fd6-a41a-e9a5-1b4f-290bb5c627fc"><br>
<ul style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr" style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">One thing we care about in particular, given the implementation of pytype, is the detailed definition of what goes in a .pyi file. Do folks think this makes sense to include as part of PEP 484, or would this be better in a separate PEP? We’d love to get your thoughts.</span></p></li>
</ul>
</b></div>
</blockquote>
It would be useful to define - on a semantic, not syntactic level -
what constructs a type checker is expected to understand. Not only
for implementers, but more importantly for stub authors. Sometimes
it's hard to judge, what constructs type checkers will understand.
And while by now I think I personally have a solid understanding of
what mypy understands, I have no idea whether that also applies to
pytype, PyCharm, or other type checkers.<br>
<br>
For example, in one of my first pull requests for typeshed, I tried
to use the following construct, expecting type checkers to
understand it:<br>
<br>
class Foo:<br>
def bar(self) -> None:<br>
raise NotImplementedError()<br>
<br>
It seems they don't, but mypy understands:<br>
<br>
class Foo:<br>
@abstractmethod<br>
def bar(self) -> None: ...<br>
<br>
But do I need to import abstractmethod? Would @abc.abstractmethod
also work? Can I have an assignment "_am = abc.abstractmethod" and
then @_am would work? Can I alias functions by using assignments in
stubs or should I use a second function definition? How complex can
Python version checks be? There are many more of those questions.<br>
<br>
If these expectations would be documents, implementers of type
checkers can still decide not to support certain constructs (or not
support them yet), or even to support more constructs. But at least
such a deviation could be documented, so users know what to expect.
On the other hand, stub authors will know what constructs will
likely not work and should be avoided.<br>
<br>
- Sebastian<br>
</body>
</html>