Allow using modules as subtypes of protocols

[ilevkivskyi]

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:

# file default_config.py
timeout = 100
one_flag = True
other_flag = False

# file __main__.py
import default_config
from typing import Protocol

class Options(Protocol):
    timeout: int
    one_flag: bool
    other_flag: bool

def setup(options: Options) -> None:
    ...

setup(default_config)  # OK

This will allow better typing than just types.ModuleType and should be straightforward to implement. Are there any objections against this?

[gvanrossum]

SGTM.

[gvanrossum]

(As long as you add it to the PEP -- preferably as a separate PR.)

[JukkaL]

Sounds good. We should perhaps explicitly specify how module-level functions would work, since they don't take a self argument. 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?

[ilevkivskyi]

@JukkaL Yes, I think just dropping the self is what everyone would expect.

[shoyer]

Another use case would be interchanging the random module and random.Random objects. (Or numpy.random and numpy.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()

[ilevkivskyi]

This 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).

[jbcpollak]

looks like the PEP was merged two years ago, but this is still an open issue. Is there any progress on this?

[hjwp]

Is 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.

[jbcpollak]

I 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?

[ilevkivskyi]

is it something a newbie can do?

Hm, I think this is not the best first issue.

[hjwp]

sorry for lecturing :sweat_smile:

[JukkaL]

Removed the "needs discussion" label since we would definitely want to have this. However, the design of the implementation will still need some discussion :-)

[seiyab]

pyright seems to have implemented this feature. It holds self in arguments. And also allows @staticmethod without self. https://github.com/microsoft/pyright/blob/d385058fe6b2d6e06eed648a96911240661e2750/packages/pyright-internal/src/tests/samples/protocolModule2.py#L7-L16 https://github.com/microsoft/pyright/commit/d385058fe6b2d6e06eed648a96911240661e2750

[theCapypara]

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.

[hauntsaninja]

@theCapypara your issue is unrelated. Do

if TYPE_CHECKING:
    a_concrete: A
    a_proto: AProtocol = a_concrete