Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix mypy errors#3

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
SSteve wants to merge1 commit intodavecom:master
base:master
Choose a base branch
Loading
fromSSteve:fix-mypy-error
Open

Conversation

SSteve
Copy link
Contributor

I get the errorIncompatible return value type (got "Tuple[C, ...]", expected "Tuple[C, C]") from mypy in genetic_algorithm.py. These changes eliminated the error but I'm still new to type hints in Python so I'm not 100% sure this is an appropriate change.

Fix mypy error `Incompatible return value type (got "Tuple[C, ...]", expected "Tuple[C, C]")`
@davecom
Copy link
Owner

Yeah, I went through the same thing when writing this last year and I decided to leave it the way it is even though mypy complained. Here's my thinking—we know these methods are supposed to return a tuple oftwo things. So, in this case I think our hints are correct even though mypy says they are not. My understanding is that the "fixed" hint is saying we will return a tuple of multiple things of the same type. Now, it probably wants that because technically methods like choices() and nlargest() could return more than 2 things, so that's what their type signatures say. But the parameters we are using ensure they always return 2. So, even though our hints are technically wrong for the purposes of type checking, they are right for the purposes of readability.

Does that make sense? I'm going to leave this open so we can discuss it further. I am open to changing it though if the consensus is that it's more important the type hints be type checker correct than human reader correct.

@SSteve
Copy link
ContributorAuthor

Your reasoning definitely makes sense. It's that trade-off of doing what you know is correct or writing to the limitations of the type checker. I'm using Visual Studio Code with my linter set to mypy so I tend to write to the limitations of the type checker. Otherwise I havePROBLEMS ❷ yelling at me all the time. But I'd never argue that this is the one and only way to do it.

davecom reacted with thumbs up emoji

antoniomolinabravo referenced this pull request in antoniomolinabravo/ClassicComputerScienceProblemsInPythonMar 1, 2023
solución con menos iteraciones, utilizando los promedios entre pares e impares se aproxima mas rápido al numero exacto
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@SSteve@davecom

[8]ページ先頭

©2009-2025 Movatter.jp