Relaxing usage of `type` with `typing.Protocol` in typing spec
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 1.8k
- 派生
- 302
- 平均合并
- 23 小时
- 30 天内合并 PR
- 8
描述
Some time ago I opened a thread on the Python discourse about implementing an AbstractType semantic that would allow functions to receive non-instantiable types so to try and conform a bit the situation presented in the the thread.
Consider the snippet:
from abc import abstractmethod
from typing import runtime_checkable, Protocol, TypeVar, TypeGuard
@runtime_checkable
class MyProtocol(Protocol):
@abstractmethod
def my_method(self) -> str:
...
class MyClass:
def my_method(self) -> str:
return "Hello from MyClass!"
class MyOtherClass:
def another_method(self) -> str:
return "Hello from MyOtherClass!"
P = TypeVar('P', bound=MyProtocol)
def check_protocol(obj: object, protocol: type[P]) -> TypeGuard[P]:
return isinstance(obj, protocol)
# Example usage
my_obj = MyClass()
my_other_obj = MyOtherClass()
if check_protocol(my_obj, MyProtocol):
print(my_obj.my_method())
if check_protocol(my_other_obj, MyProtocol):
print(my_other_obj.my_method())
else:
print("Object does not implement MyProtocol.")
Output:
Hello from MyClass!
my_obj does not implement MyOtherClass protocol.
At runtime, this works as intended. At type checking time, mypy complains that check_protocol cannot accept a non-instantiable type, while pyright and ty are accepting this behavior.
According to the typing specification, mypy is technically correct (the best kind of correct), but this code is perfectly acceptable. There are other examples referenced in python/mypy#4717 (which is the 3rd most upvoted issue by 👍 by the way).
I was hoping for more discussion points presented in the thread but not many replied. I didn't want to monopolize it, so I'm trying my luck here.
@JelleZijlstra (sorry for the ping) did point out that it might be worthwhile to change the spec to allow this behavior but I'm guessing there should be some discussion on how to deal with it first. Jelle suggested: "If you want it to be instantiable, use Callable[] instead."
I do agree it makes sense, but this snippet:
from typing import Protocol
class MyProtocol(Protocol):
def method(self) -> str:
...
print(callable(MyProtocol)) # prints True
confuses me.
So my point is: could the spec allow for type to accept non-instantiable types, since it seems to be a pretty common pattern? Is there a way to effectively deal with the separation between instantiable and non-instantiable types?
I tried adding the "typing spec" label but couldn't. At any rate, thank you for the consideration.
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
先阅读关于 typing 规范的讨论和链接的 Python Discourse 主题,然后比较其中针对 mypy、pyright 和 ty 所描述的行为。查看 mypy#4717 以了解相关示例。完成的标准是就 type[P] 是否可以接受不可实例化的 Protocol 类型达成一致,并记录由此产生的规则。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- python
- 领域
- documentation
- Issue 类型
- 功能
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 冷清
- 描述清晰度
- 需要澄清
- 新手友好度
- 35/100