This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps an informational one?). I hope you understand that I am not volunteering.
On Tue, Jul 17, 2018 at 1:51 AM, Sebastian Rittau <srit...@rittau.biz> wrote: > 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 > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com