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/archive%40mail-archive.com
