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 mypy errors #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix mypy errors #3

wants to merge 1 commit into from

Conversation

SSteve
Copy link
Contributor

@SSteve SSteve commented Feb 19, 2019

I get the error Incompatible 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

davecom commented Feb 19, 2019

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 of two 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
Contributor Author

SSteve commented Feb 19, 2019

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 have PROBLEMS ❷ yelling at me all the time. But I'd never argue that this is the one and only way to do it.

antoniomolinabravo referenced this pull request in antoniomolinabravo/ClassicComputerScienceProblemsInPython Mar 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 free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants