You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Builtin classes str and list inherit from Sequence and indirectly from Protocol, which implies that register is available for those classes, which is not correct.
In Python it is possible to use register on a Protocol, but not on str:
>>> from typing import Protocol
>>> class Foo(Protocol):
... x: str
...
>>> Foo.register(int)
<class 'int'>
>>> str.register(int)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: type object 'str' has no attribute 'register'
In Mypy it is valid to use register on Protocols, but it's also possible to write str.register(int) or list.register(int), which is incorrect.
In Pyright register doesn't work on all protocols:
from typing import Protocol
list.register(int) # Doesn't work (which is correct)
class Foo(Protocol):
x: str
Foo.register(int) # Also doesn't work (but it should)
So it feels that both Mypy and Pyright are not correct here and typeshed itself doesn't really help. I feel it is kind of wrong that str and list inherit from Protocols, but I can understand that it reduces a lot of duplicate code in stubs. Is there another way how we could improve this situation? Should we add a marker for those cases where a class inherits from a Protocol in typeshed, but is not really a Protocol during runtime?
The text was updated successfully, but these errors were encountered:
Builtin classes
str
andlist
inherit fromSequence
and indirectly fromProtocol
, which implies thatregister
is available for those classes, which is not correct.In Python it is possible to use
register
on a Protocol, but not onstr
:In Mypy it is valid to use
register
on Protocols, but it's also possible to writestr.register(int)
orlist.register(int)
, which is incorrect.In Pyright
register
doesn't work on all protocols:So it feels that both Mypy and Pyright are not correct here and typeshed itself doesn't really help. I feel it is kind of wrong that
str
andlist
inherit from Protocols, but I can understand that it reduces a lot of duplicate code in stubs. Is there another way how we could improve this situation? Should we add a marker for those cases where a class inherits from a Protocol in typeshed, but is not really a Protocol during runtime?The text was updated successfully, but these errors were encountered: