Repository navigation
Allow using modules as subtypes of protocols #5018
Description
Activity
- SGTM.
- (As long as you add it to the PEP -- preferably as a separate PR.)
Sounds good. We should perhaps explicitly specify how module-level functions would work, since they don't take a
selfargument. Example:# m.py def f(x: int) -> None: pass # main.py import m from typing import Protocol class P(Protocol): def f(self, x: int) -> None: ... p: P = m # Should be ok?
@JukkaL Yes, I think just dropping the
selfis what everyone would expect.Another use case would be interchanging the
randommodule andrandom.Randomobjects. (Ornumpy.randomandnumpy.random.RandomState.)This is a nice way to make functions that either use the global RNG state or support overloading with explicit objects, e.g.,
import random from typing import Protocol class Random(Protocol): ... # all methods from random.Random def random_add(rng: Random = random): return rng.rand() + rng.rand()
Reacted by Paul Ganssle and Nikolaus WaxweilerThis is a nice way to make functions that either use the global RNG state or support overloading with explicit objects, e.g.,
Yes, I think everyone is sold on this (there is already a PR to add this to the PEP 544), but we just didn't have time to implement this (even though it is pretty straightforward).
- added a commit that references this issue
on May 11, 2019 looks like the PEP was merged two years ago, but this is still an open issue. Is there any progress on this?
Reacted by Dominic Davis-Foster and Fran HrženjakIs there any progress on this?
Please don't do this. You can see there's been no progress. Nagging only makes the (unpaid, volunteer) maintainers feel stressed and underappreciated. If you really need a feature, the best thing you can do is to dig into the codebase and open a PR.
Reacted by Dominic Davis-Foster and Ari EntlichReacted by Guido van Rossum and Peter NovotnakI understand the etiquette, but from looking at the messages its unclear what the current state is - conversation seems to have just stalled. Its also labeled 'needs discussion'. @ilevkivskyi mentioned its straight forward work, what needs to be done? is it something a newbie can do?
Reacted by Dominic Davis-Foster and mangelozziis it something a newbie can do?
Hm, I think this is not the best first issue.
sorry for lecturing 😅
Reacted by 7iWRemoved the "needs discussion" label since we would definitely want to have this. However, the design of the implementation will still need some discussion :-)
Reacted by Seiyapyright seems to have implemented this feature.
It holdsselfin arguments.
And also allows@staticmethodwithoutself.
https://github.com/microsoft/pyright/blob/d385058fe6b2d6e06eed648a96911240661e2750/packages/pyright-internal/src/tests/samples/protocolModule2.py#L7-L16
microsoft/pyright@d385058Reacted by Harry Percival, Nikolaus Waxweiler and Greg Werbin- added a commit that references this issue
on Jan 7, 2022 Is there at least a workaround for this? It seems even classes (the classes itself not the instances!) can't be tested against protocols:
from typing import Protocol class AProtocol(Protocol): a: str class A: a = "a" a_ex: AProtocol = A
results in
Incompatible types in assignment (expression has type "Type[A]", variable has type "AProtocol")Or is there no way at the moment with mypy to check protocols for "non-instantiated" objects? I need this functionality to check some static generated code.
Reacted by Michał Prochera@theCapypara your issue is unrelated. Do
if TYPE_CHECKING: a_concrete: A a_proto: AProtocol = a_concrete- added a commit that references this issue
on Aug 27, 2022
There is an idea to allow modules be accepted where a protocol is expected. This pattern is sometimes used for configs and option management, for example:
This will allow better typing than just
types.ModuleTypeand should be straightforward to implement. Are there any objections against this?