Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix a bunch of typing errors #4024

Merged
merged 6 commits into from
Nov 13, 2021

Conversation

danieleades
Copy link
Contributor

this pull request takes the total number of mypy errors from 656 to 617

it's a start...

@abn
Copy link
Member

abn commented May 6, 2021

I do not think most of these are required. The only one that I can see as being the right change is at 943fb35#diff-89c37d9db9d559ea6d241ff3fcbee2053643e688e99a177327fd0ad15580ba26R239.

@danieleades
Copy link
Contributor Author

I do not think most of these are required. The only one that I can see as being the right change is at 943fb35#diff-89c37d9db9d559ea6d241ff3fcbee2053643e688e99a177327fd0ad15580ba26R239.

These are all required in the sense that the original code is an error with respect to the current mypy configuration.

The return errors could be suppressed with a config change.

There's a number of cases where I've swapped variant types for invariant types. This is required for correctness. See https://mypy.readthedocs.io/en/latest/generics.html#variance-of-generic-types

Comment on lines 480 to +503
def _populate_local_repo(
self, local_repo: Repository, ops: List[Operation]
self, local_repo: Repository, ops: Sequence[Operation]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abn
here's an example of the use of a 'covariant' type (required for correctness)

the _populate_local_repo method accepts ops: List[Operation], however Operation is a base class. In practice we expect that this method should accept a list of some derived class (such as Uninstall, for example).

the problem is that List[Subclass] is not equivalent to List[Baseclass] (see these docs - http://mypy.readthedocs.io/en/latest/generics.html#variance-of-generic-types)

however Sequence[Subclass] is equivalent to Sequence[Baseclass]. Similarly, Iterable[Subclass] is equivalent to Iterable[Baseclass].

) -> Iterator[str]:
) -> Iterable[str]:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abn
this too is a correctness bug. the returned value of this function is not an iterator, but it is a type than can be converted into an iterator. That's the distinction between Iterator and Iterable

Comment on lines 1119 to +1232
return Path(self.paths["usersite"])
return None
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abn
explicitly returning None is required to conform with PEP8 and to satisfy mypy

from PEP8-

Be consistent in return statements. Either all return statements in a function should return an expression, or none of them should. If any return statement returns an expression, any return statements where no value is returned should explicitly state this as return None, and an explicit return statement should be present at the end of the function (if reachable)

it's not without controversy, see this discussion - python/mypy#7511

it depends what the goal is. The goal of this pull request is not strictly correctness, it is to reduce the amount of noise that mypy makes, in the hope that this is a small step in the direction of actually being able to effectively use Mypy to lint this codebase (and also correctness!).

In a perfect world, the number of type errors would be 0, and then mypy could be added as a pre-commit hook or CI job to ensure type errors are not reintroduced. Baby steps.

Comment on lines -6 to -7
if TYPE_CHECKING:
from poetry.utils.env import Env
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this pattern is used in the case that an unconditional import would cause a circular import. This isn't required here.

Comment on lines -462 to +463
def _single_term_where(self, callable: callable) -> Optional[Term]:
def _single_term_where(self, callable: Callable[[Term], bool]) -> Optional[Term]:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the built-in callable can't be used for type annotations

) -> "ProjectPackage":
) -> None:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this method doesn't return...

Comment on lines -1330 to +1437
def __eq__(self, other: "Env") -> bool:
def __eq__(self, other: object) -> bool:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is required to satisfy Liskov subsitution principle- namely that the derived class's __eq__ should have the same, or a less restrictive function signature for any overridden baseclass methods.

Comment on lines -1581 to +1783
def _run(self, cmd: List[str], **kwargs: Any) -> int:
def _run(self, cmd: List[str], **kwargs: Any) -> Optional[int]:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change, while correct, actually increases the total number of errors, since the None case is not handled in the calling code.

@@ -61,7 +62,7 @@ def get(cls) -> "Shell":

return cls._shell

def activate(self, env: VirtualEnv) -> None:
def activate(self, env: VirtualEnv) -> Optional[int]:
if WINDOWS:
return env.execute(self.path)
Copy link
Contributor Author

@danieleades danieleades May 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this method returns Optional[int]

@danieleades
Copy link
Contributor Author

Ping @abn

@danieleades danieleades force-pushed the refactor/typing branch 2 times, most recently from 2e1d4c1 to d22069f Compare June 3, 2021 08:10
@sonarcloud
Copy link

sonarcloud bot commented Jun 3, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

No Coverage information No Coverage information
0.0% 0.0% Duplication

@danieleades
Copy link
Contributor Author

@abn do you mind approving the workflows?

@danieleades
Copy link
Contributor Author

rebased. @abn, it's that time again...

Copy link

@skovhus skovhus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very solid and I cannot see any controversial changes here. I hope this gets merged soon.

@danieleades
Copy link
Contributor Author

This looks very solid and I cannot see any controversial changes here. I hope this gets merged soon.

i'm not holding my breath...

@danieleades
Copy link
Contributor Author

@abn there's over 700 typing errors now in this repo, even after these changes. Is there any appetite for reducing/resolving these?

Copy link
Member

@neersighted neersighted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this work! I'm very interesting in getting the typing issues reduced and getting mypy into the Code Quality checks. Feel free to reach out offline (e.g. Discord) to coordinate on this.

@neersighted neersighted merged commit a49372a into python-poetry:master Nov 13, 2021
1nF0rmed pushed a commit to 1nF0rmed/poetry that referenced this pull request Nov 15, 2021
edvardm pushed a commit to edvardm/poetry that referenced this pull request Nov 24, 2021
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants