Why Do Python Protocols with Generic Types Show Unexpected Variance Behavior?

Below is an explanation of each case along with some background on how protocol‐method checking (and its variance) is implemented in Python’s type system. (Note that differences between static type checkers exist; in this case PyCharm’s analyzer is being used.)

---

1. Invariant Protocol with the "Feeder" Example

Your protocol is defined as

PYTHONCopied
class Feeder(Protocol[T]):
    def feed(self, animal: T) -> T: ...

Because the type variable T is declared without any variance marker, it is invariant with respect to the protocol. In a strictly “nominal” setting the following two directions must hold for a method “feed” with signature S→T:

  • When checking subtyping of callable types, parameters are contravariant and results are covariant.

Thus, to allow an implementation of Feeder[Animal] to be used where Feeder[Dog] is expected, you would need that DogFeeder.feed
(i.e. a function of type Dog → Dog) be a valid substitute for a function of type Animal → Animal. In the parameter position this would require Dog to be a supertype of Animal, which is false.

So by the standard rules you would expect that DogFeeder is not a valid Feeder[Animal]. And indeed if you write

PYTHONCopied
feeder2: Feeder[Dog] = AnimalFeeder()  # rejected

the type checker rightly complains. However, note that in your third case you have

PYTHONCopied
feeder3: Feeder[Animal] = DogFeeder()

Even though the “feed” method in DogFeeder is written as accepting a Dog instead of a general Animal, many static checkers (including PyCharm’s) use a bivariant checking for instance methods in protocols. (This is an acknowledged “unsound” but pragmatic compromise in the design of structural subtyping.) In effect the parameter positions of protocol methods are not forced to be strictly contravariant when no variance is declared on the protocol’s type variable. That is why feeder3 type‑checks even though it “seems” to violate invariance.

---

2. Contravariant Protocol with the "Walker" Example

Your protocol for Walker is declared with an explicitly contravariant type variable:

PYTHONCopied
class Walker(Protocol[T_contra]):
    def walk(self, animal: T_contra) -> None: ...

For contravariant type variables the expectation is reversed: an implementation is a subtype only if the parameter type of its walk() method is a supertype of the expected one. In other words, if you require Walker[Dog] then the method should be able to accept more than just Dog (i.e. it should accept any Animal) so that it can be safely called with a Dog.

Now, examine the two cases:

• walker2:

  PYTHONCopied
  walker2: Walker[Dog] = AnimalWalker()

  Here AnimalWalker.walk takes an Animal. For contravariance we would require that the parameter type of AnimalWalker (Animal) is a subtype of the expected one (Dog) – but it isn’t. (For function parameters, subtyping goes “the other way”: a function that accepts a Dog is “more flexible” than one that accepts only Animal.)
  Thus, walker2 is rejected.

• walker3:

  PYTHONCopied
  walker3: Walker[Animal] = DogWalker()

  Here DogWalker.walk takes a Dog whereas the protocol expects a function that accepts an Animal. For contravariant parameters this is acceptable only if Dog is understood as being “narrower” than Animal. In standard contravariance the parameter type of the implementation (Dog) must be a supertype of the expected one (Animal). In other words, if a caller always passes an Animal to the protocol method then the DogWalker (which expects Dog) might seem like it should be rejected.
  However, as with our Feeder case, many protocol checkers (including PyCharm’s) apply a less strict, “bivariant” treatment to instance methods in protocols even when variance markers are present. In this case the analyzer allows walker3 even though from a purely theoretical contravariant view it is unsound.

---

3. Are These Behaviors “Correct”?

The behaviors you see are indeed a product of the current practical implementation of structural subtyping with protocols in Python. In summary:

• Feeder: The absence of an explicit variance marker for T and the way methods are checked (often “bivariantly”) makes the assignment

  PYTHONCopied
  feeder3: Feeder[Animal] = DogFeeder()

  pass even though a strict application of parameter contravariance would not allow it.

• Walker: With an explicitly contravariant type variable, the method parameter types are expected to follow contravariant rules. In walker2 the mismatch is caught as expected. In walker3 the analyzer’s treatment (which again tends toward bivariant checking for protocol methods) allows assignment even if it seems unsound in a stricter setting.

These behaviors are known limitations of (and compromises in) current static type checking for Python protocols. Different type checkers (mypy, Pyright, PyCharm) may be subtly different, and there are ongoing discussions (and even PEP proposals) about how best to handle method variance in protocols.

---

Bottom Line

• The fact that feeder3 type-checks is due to the analyzer’s “bivariant” treatment of protocol methods when no explicit variance is declared on the protocol’s type variable.
• Walker2 fails because for the contravariant case the checker does enforce a “stricter” contravariant relationship, whereas walker3 is allowed because of the relaxed/bivariant treatment in protocol method checking.
• Thus, these behaviors are a result of the practical implementation of Python’s static type system; they do not represent a deviation from the design but rather a known limitation/compromise that different tools handle differently.

If you need stricter checking you might explore using a fully stricter type checker (such as mypy with more flags) to see if the variance issues are caught; however, some unsoundness in protocol method checking remains a practical reality in Python’s typing.