ReturnType violation for protocol's method with docstring

[EnderASz]

Hi, I recently started using Pyright as my typechecker and in most cases I have no problems with that - that's really great tool. But today I met some behaviour I don't really understand. I think it would be the best to show an example first.

import typing as t

class SomeProtocol(t.Protocol):
    def some_meth(self) -> int:    # pyright error: Function with declared return type "int" must return value on all code paths
        """
        Some docstring documentation
        """

This happens only when I don't provide an ellipsis (...) in method body here.

import typing as t

class SomeProtocol(t.Protocol):
    def some_meth(self) -> int:    # No error here - everything seems fine
        """
        Some docstring documentation
        """
        ...

Why do I still need ellipsis in method body? As it is a protocol it should be obvious that there should not be any implementation there. When i don't provide docstring there - it's understandable I need ..., because there must be something. But when I have docstring there already - it should be enough I think.

[erictraut]

This is by design. You must include a ... to indicate to pyright that the implementation is a placeholder and not an actual implementation that returns an implicit None.

This is an area that is under-specified in the typing spec, but I think that pyright's current design here is defensible, and I will be pushing for it to become the officially-documented behavior in protocols. In any case, I don't plan to change its behavior until we have this discussion in the typing forums and reach consensus about a specified behavior.

[EnderASz]

Thanks for the answer ^^
As I understand it's just following the rule "explicit is better than implicit" and giving ... some definition in this context.

This decision is fully understandable for me now and I agree with you - it should be specified in typing spec.

[josmithua]

FYI this clashes with pylint rule W2301