Skip to content

Not resolving nested protocol when combined through multiple inheritance #5998

Closed

Description

@willtalmadge
  • Are you reporting a bug, or opening a feature request?

This may be a bug if it is not intended behavior.

  • Please insert below the code you are checking with mypy,
    or a mock-up repro if the source is private. We would appreciate
    if you try to simplify your case to a minimal repro.

I've constructed the following minimal example that demonstrates the issue. I've placed a comment before the line where mypy is having a problem.

from dataclasses import dataclass
from typing import List

from typing_extensions import Protocol


class Name(Protocol):
    first: str
    last: str


class HasWand(Protocol):
    has_wand: bool


class NameProp(Protocol):
    name: Name


class Wizard(NameProp, HasWand, Protocol): ...


def wand_report(arg: Wizard) -> None:
    print(arg.name.first)
    print(arg.name.last)
    if arg.has_wand:
        print('This wizard has a wand.')
    else:
        print('This wizard needs to visit Ollivanders.')


@dataclass
class NameExtended:
    first: str
    last: str
    middle_names: List[str]


@dataclass
class DarkWizard:
    name: NameExtended
    at_large: bool
    power_level: int
    has_wand: bool = True


carl = DarkWizard(
    name=NameExtended(
        first='Carl',
        last='Fizzlbuz',
        middle_names=['Modfife']
    ),
    power_level=2,
    at_large=True,
)

# Pycharm is fine with the following line, as I'd expect, since 'NameExtended'
# structurally implements 'Name'. mypy complains about this line.
wand_report(carl)
  • What is the actual behavior/output?
nest_protocols.py:59: error: Argument 1 to "wand_report" has incompatible type "DarkWizard"; expected "Wizard"
nest_protocols.py:59: note: Following member(s) of "DarkWizard" have conflicts:
nest_protocols.py:59: note:     name: expected "Name", got "NameExtended"
  • What is the behavior/output you expect?
    I would expect no error to be raised for the file above with the --strict flag.
  • What are the versions of mypy and Python you are using?
    mypy 0.641
    Python 3.7.1
  • Do you see the same issue after installing mypy from Git master?
    Yes
  • What are the mypy flags you are using? (For example --strict-optional)
    --strict

Activity

  1. ilevkivskyi commented on Dec 3, 2018

    @ilevkivskyi
    Member

    Your code is actually unsafe, see for example https://mypy.readthedocs.io/en/latest/common_issues.html#covariant-subtyping-of-mutable-protocol-members-is-rejected. To make it safe you need to make name read-only, for example a @property in the NameProp protocol.

  2. ilevkivskyi commented on Dec 3, 2018

    @ilevkivskyi
    Member

    (no need to make it read-only in the implementations)

  3. willtalmadge commented on Dec 5, 2018

    @willtalmadge
    Author

    Thanks for helping me understand this. This type of issue makes me glad mypy exists. This is a bug that would be hard to spot in a larger code base without the help of the type checker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions