[Python-Dev] Question about PEP 484

[Guido van Rossum]

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>