Moreover, extensive use of ABCs might impose additional runtime costs.

Do we have any numbers? We know ABCs aren't free but I don't know if this is worth mentioning unless it's a major factor. The rationale for protocols to be the pythonic, dynamic and idiomatic version of ABCs is strong enough.

class C(collections.abc.Iterable):
    def __iter__(self):
        return []

is 2x slower than

class C:
    def __iter__(self):
        return []

The numbers for typing.Iterable are even worse, but I have some ideas on how to improve those. The 2x slowdown is still not much, so I use "extensive" and "might". If you think it is not necessary we could remove this altogether.

It is also automatically extensible and works with additional, unrelated classes that happen to implement the required protocol.

Yes, this is the killer feature.

I'm worried this could be pretty confusing: you could have a class that explicitly implements some protocols and implicitly implements others. I don't know of any other language that allows this.

If X is a protocol itself, "implements" gets a different meaning, right? I think in that case it just means that it must define all of P's methods right? Maybe it would be less ambiguous if you separated the two cases into separate bullets.

Maybe it would be less ambiguous if you separated the two cases into separate bullets.

I agree.

I'd consider leaving out All from this proposal, at least initially. This is something we can add later if there is a need, but currently I don't see evidence for this being important. Effectively the same behavior can be achieved through multiple inheritance. Besides, it would be a bit arbitrary if All only worked with protocols, and making All work with arbitrary types would be a much more complex feature, and not as directly related to this PEP.

I think we could include this for three reasons:

• I could easily imagine a function parameter that requires more than one protocol, especially if the preferred style is to have several simple protocols, rather than few complex. By the way, some classes in collections.abc are simple intersections, for example Collection == All[Sized, Iterable, Container].
• It could be easily implemented for protocols. I also propose to use All instead of Intersection to emphasize it only works for protocols (mnemonics: variable implements all these protocols). On the contrary, I think that intersections of nominal classes would be very rarely used.
• If we decide to include this later, then people might simply be not aware of this feature (this is a minor reason, but still we need to take this into account).

I agree with Jukka -- I think it's confusing for All to work only with protocols, extending All to work with all types would add considerable complexity, and I'm not convinced there's a pressing need.

I was pushing for Intersection for the original PEP because I saw the need for being able to intersect ABCs. Given that protocols themselves solve this, and we can use multiple inheritance as Jukka is suggesting, I agree that it's wiser to leave this out.

I would still like to have it, but that can be a separate PEP. I agree it's complex to implement for concrete types, and better yet, for combinations of both.

For non-protocol classes, the behavior of Type[] is not changed.

No, we want to make ABCs behave the same way.

I don't love the automatic isinstance check support, even though that's how the mypy Protocol class used to work. I don't think that they can be made to work reliably for arbitrary ABCs. Consider this example:

class P(Protocol):
    @abstractmethod
    def common_method_name(self, x: int) -> int: ... 

class X:
    <a bunch of methods>
    def common_method_name(self) -> None: ...

def do_stuff(o: Union[P, X]) -> int:
    if isinstance(o, P):
        return o.common_method_name(1)  # oops what if it's an X instance instead?
    else:
        return (do something with an X)

Maybe a type checker can warn about this example, but more generally the isinstance check could be unreliable, except for things where there is a common signature convention such as Iterable.

Another potentially problematic case:

class P(Protocol):
    x: int

class C:
    def initialize(self) -> None:
        self.x = 0

c1 = C()
c2 = C()
c2.initialize()
isinstance(c1, P)  # False
isinstance(c2, P)  # True

def f(x: Union[P, int]) -> None:
    if isinstance(x, P):
        # type of x is P here
        ...
    else:
        # type of x is int here?
        print(x + 1)

f(C())   # oops

Again, maybe we can live with this, but this could be pretty surprising. I'd argue that requiring an explicit class decorator would be better, since we can then attach warnings about problems like this in the documentation. The programmer would be able to evaluate whether the benefits outweigh the potential for confusion for each protocol and explicitly opt in -- but the default behavior would be safer.

I'd argue that requiring an explicit class decorator would be better, since we can then attach warnings about problems like this in the documentation.

This is how I initially wrote this, since I intuitively felt that this could not be 100% reliable. Guido wanted to make it default, by now we have good examples to make this opt-in, so that I will revert this to class decorator.

I'm not sure I understand how a class decorator would solve the problem. Wouldn't that mean that some classes that implement the protocol (i.e. the decorated ones) will work properly with isinstance at runtime but others will not?

classes that implement the protocol (i.e. the decorated ones)

The decorator is applied to protocol, not to implementation. This was in a previous draft. At runtime the decorator will add same __subclasshook__() to a protocol, that collections.abc classes have now. As Jukka pointed out, there are pros and cons of such approach, and a user could decide.

How would the __subclasshook__ work?

Basically, if a class has all necessary attributes, then it is a subclass. This is why I mention below that "type checkers will narrow types after such checks by the type erased Proto (i.e. with all variables having type Any and all methods having type Callable[..., Any])" because we cannot reliably check the types of attributes at runtime.

This is how it is done in collections.abc see https://github.com/python/cpython/blob/master/Lib/_collections_abc.py#L72 and e.g. https://github.com/python/cpython/blob/master/Lib/_collections_abc.py#L93

How do you propose to handle the backwards-incompatibility problem for all currently released versions of Python?

The idea is that there should be no backward incompatibility. The classes in typing module (as well as in collections.abc) already behave like protocols at runtime:

class Whatever:
    def __iter__(self): return []
assert isinstance(Whatever(), Iterable)

as I mention below "Practically, few changes will be needed in typing since some of these classes already behave the necessary way at runtime", most of these will be changed only in typeshed.

Also, after I implement the changes proposed by Jukka, all code that passes mypy now, will still pass (unless I don't see some subtleties).

"In Go language" -> either "In Go" or "In the Go language"