osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Question about PEP 484


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