I see some utility in this idea, but I'm not sure if it's sufficient to merit a new facility. The use cases it supports strike me as relatively rare. Maintaining separate protocol class definitions doesn't seem to be that much of a burden for these infrequent use cases. But I'm interested in hearing from others. A few additional things to consider. Since all real classes subclass from `object`, I presume that the derived protocol would not automatically include all of the methods and attributes defined in `object` unless they were explicitly defined by the template class or one of its parent classes (other than object). That includes methods like `__eq__`, `__hash__`, and `__repr__`. The `.from` form looks odd to me. I think it would be more consistent with existing forms (e.g. `NewType` or `NamedTuple`) to adopt this form: ```python SomeClassProtocol = Protocol("SomeClassProtocol", SomeClass) ``` It's not clear to me how this would work for generic classes. Would the type variables used in the template class be adopted implicitly by the protocol class that's derived from the template? Does the same apply to type variables referenced by methods and non-method attributes? There's no precedent for implicit type variables anywhere else in the type system today, so this strikes me as a potential problem. Maybe the type variables need to be explicit, like this? ```python SomeClassProtocol = Protocol("SomeClassProtocol", SomeClass[_K, _V]) ``` How would type checkers differentiate between class variables and instance variables? PEP 526 provides a way to differentiate using `ClassVar`. Protocol class definitions tend to use `ClassVar` properly, but I rarely see it used in non-protocol class definitions. What about attributes that have no type annotation (e.g. the statement `self.foo = 3` within a method body)? Would they be included in the derived protocol class? -Eric -- Eric Traut Contributor to Pylance & Pyright Microsoft Corp.

A similar proposal, just FYI https://github.com/python/mypy/issues/7894 On Fri, May 21, 2021 at 11:41 PM James Perretta <perretta.james@gmail.com> wrote:

Hi everyone,

One of the rejected ideas in PEP 544 is being able to define a Protocol that inherits from a normal class ( https://www.python.org/dev/peps/pep-0544/#protocols-subclassing-normal-class...). I've been thinking about a potential new feature that could accomplish more or less the same thing without running into the transitivity issue described in PEP 544. I'm sure there are some considerations I've missed, but I'd love to hear what you all think.

In short, we'd introduce a +`.from()` method to typing.Protocol that takes in a class and returns a new Protocol with the same interface as that class. ``` from typing import Protocol

class SomeClass: def some_method(self) -> None: pass

class SomeClassProtocol(Protocol.from(SomeClass)): def another_method(self) -> None: ... ```

Static type checkers would in this case determine that SomeClassProtocol is a Protocol with two methods (some_method and another_method). If SomeClass and SomeClassProtocol both define a method with the same name, the one defined in SomeClassProtocol would take precedence.

The next thing to think about would be: - Should the result of Protocol.from(SomeClass) only include SomeClass's methods, or should it include methods and attributes? - By default, I think it should probably include methods and attributes. There could possibly be an optional argument to Protocol.from() that toggles whether attributes are included, something like: `Protocol.fom(SomeClass, include_attrs=False)` - Should it include only "public" members, or should it also include `_` and `__` prefixed names? - My inclination would be that it should only include public members.

Some other things to consider that I'm still thinking about: - What would SomeClassProtocol look like at runtime? I suppose Protocol.from(SomeClass) could introspect SomeClass at runtime and essentially build a protocol class that shares has SomeClass's interface? - Would this play nicely with generics? (I think/hope so?)

One general use case (there are certainly others that I'm not thinking of at the moment) for this is when annotating "self" for a mixin class ( https://mypy.readthedocs.io/en/stable/more_types.html#mixin-classes). It's at best cumbersome to have to write a protocol that matches an existing class and keep them in sync, and it's even more problematic if the protocol needs to match a class from another library.

If this idea seems useful enough to move forward, I'd be happy to help write a PEP for it and work on a mypy implementation (this would be my first time writing a PEP or contributing to mypy). Looking forward to hearing your thoughts!

Thanks, James _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: epsilonmichael@gmail.com