[Python-Dev] Question about PEP 484 (original) (raw)

Guido van Rossum guido at python.org
Tue Jul 17 11:05:47 EDT 2018

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 <srittau at 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 at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180717/4c1bb829/attachment.html>

More information about the Python-Dev mailing list