On 16.07.2018 19:21, Adam Cataldo via Python-Dev wrote:
*
*
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.
* 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.
For example, in one of my first pull requests for typeshed, I tried to use the following construct, expecting type checkers to understand it: class Foo: def bar(self) -> None: raise NotImplementedError() It seems they don't, but mypy understands: class Foo: @abstractmethod def bar(self) -> None: ... 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. 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. - Sebastian