Skip to content

Various ruff fixes #12821

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

Merged
merged 1 commit into from
Jul 5, 2025
Merged

Various ruff fixes #12821

merged 1 commit into from
Jul 5, 2025

Conversation

cclauss
Copy link
Member

@cclauss cclauss commented Jul 5, 2025

Describe your change:

Make changes required to pass current ruff tests.

  • Add an algorithm?
  • Fix a bug or typo in an existing algorithm?
  • Add or change doctests? -- Note: Please avoid changing both code and tests in a single pull request.
  • Documentation change?

Checklist:

  • I have read CONTRIBUTING.md.
  • This pull request is all my own work -- I have not plagiarized.
  • I know that pull requests will not be merged if they fail the automated tests.
  • This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
  • All new Python files are placed inside an existing directory.
  • All filenames are in all lowercase characters with no spaces or dashes.
  • All functions and variable names follow Python naming conventions.
  • All function parameters and return values are annotated with Python type hints.
  • All functions have doctests that pass the automated testing.
  • All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
  • If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #ISSUE-NUMBER".

@algorithms-keeper algorithms-keeper bot added the tests are failing Do not merge until tests pass label Jul 5, 2025
@@ -79,7 +79,7 @@ def replace_digits(self, num: int) -> str:
>>> hill_cipher.replace_digits(26)
'0'
"""
return self.key_string[round(num)]
return self.key_string[(num)]
Copy link
Member Author

@cclauss cclauss Jul 5, 2025

Choose a reason for hiding this comment

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

@dhruvmanila I do not understand this change requested by ruff. Type hints are suggestions, not mandatory in Python. Just because the type hint says num: int, that does not guarantee that the caller will not pass in 17.23. This call to round() prevents breakage.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is correct and is https://docs.astral.sh/ruff/rules/unnecessary-round/. The num is an int so it doesn't require a round call. If you expect num to be a float as well then the type hint should be updated to int | float which is basically float.

Copy link
Member Author

@cclauss cclauss Jul 7, 2025

Choose a reason for hiding this comment

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

This misses the point. The type hint is a suggestion in Python, not an obligation. The caller may choose to send a float even though I have suggested they send an int. Without the round() call, the function will crash. With the round() call, the function will succeed. This rule is asking me not to drive defensively.

The workaround for ruff rule RUF057 is to use int(num) instead of round(num):

Copy link
Member

Choose a reason for hiding this comment

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

I don't think that's correct. From a static analysis perspective, type hints are part of the function contract that says that the num parameter here should be an int and if the caller passes a float then that's an error. So, if the function is expecting to receive a float or an int, then the contract should be updated instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

The num parameter here should be an int. Python will not prevent the caller from breaking that rule.

Using int(num) instead of round(num) ensures the function remains well-behaved in the face of garbage input.

Copy link
Member

Choose a reason for hiding this comment

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

I see. I think that depends on whether this specific function is part of the public API for this module or not. If it is, then one way to perform error handling would be to use something like:

if not isinstance(num, int):
    raise TypeError("expected an integer, but got ...")

And, if it's not part of the public API, then we shouldn't do this and instead use a type checker.

@cclauss cclauss force-pushed the more-ruff-ignore branch from 3f6da37 to d236f27 Compare July 5, 2025 09:18
@algorithms-keeper algorithms-keeper bot added awaiting reviews This PR is ready to be reviewed and removed tests are failing Do not merge until tests pass labels Jul 5, 2025
@cclauss cclauss force-pushed the more-ruff-ignore branch from a05203b to 372ee36 Compare July 5, 2025 09:25
@cclauss cclauss mentioned this pull request Jul 5, 2025
15 tasks
@cclauss cclauss enabled auto-merge (squash) July 5, 2025 12:53
@cclauss cclauss force-pushed the more-ruff-ignore branch from 4c1dc8c to 09618e8 Compare July 5, 2025 13:34
@cclauss cclauss merged commit cd3c3c3 into TheAlgorithms:master Jul 5, 2025
5 checks passed
@cclauss cclauss deleted the more-ruff-ignore branch July 5, 2025 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting reviews This PR is ready to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants