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

Enable Ruff RET501 #115031

Merged
merged 12 commits into from
Aug 8, 2024
Merged

Enable Ruff RET501 #115031

merged 12 commits into from
Aug 8, 2024

Conversation

autinerd
Copy link
Contributor

@autinerd autinerd commented Apr 6, 2024

Proposed change

This enables the Ruff rule RET501: Do not explicitly return None in function if it is the only possible return value.

This fixes the occurrences as well, either by replacing return None with return or by adding type annotations to the functions.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
  • Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

Copy link
Member

@janiversen janiversen left a comment

Choose a reason for hiding this comment

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

LGTM, thanks.

Copy link
Contributor

@jbouwh jbouwh left a comment

Choose a reason for hiding this comment

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

LGTM,
Thnx @autinerd 👍

@home-assistant home-assistant bot marked this pull request as draft April 6, 2024 22:35
@home-assistant
Copy link

home-assistant bot commented Apr 6, 2024

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@@ -82,13 +82,13 @@ class DateEntity(Entity, cached_properties=CACHED_PROPERTIES_WITH_ATTR_):
@final
def device_class(self) -> None:
"""Return the device class for the entity."""
return None
return
Copy link
Member

Choose a reason for hiding this comment

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

This is also wrong, I think. Properties should always return None explicitly since the return value will be consumed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From the runtime behavior there is no difference between return and return None. And as the function has a type annotation of -> None, there is nothing to be returned other than None.

>>> def a():
...     return
... 
>>> b = a()
>>> type(b)
<class 'NoneType'>

Copy link
Member

@MartinHjelmare MartinHjelmare Apr 7, 2024

Choose a reason for hiding this comment

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

Like I said, properties are always meant to have a return value for consumption and then we should return None explicitly, always. It's about reading the code, not about runtime behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have it now as a noqa.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @MartinHjelmare about making it explicit.

But adding a niqab to perfectly valid code is not a good way to go! that signals the code is somehow not correct!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are four options in total:

  • Adding the type hints as the property functions are in the parent classes, then there is not only None as return type
  • Adding noqa directives
  • Allowing the implicit None in all functions which only return None
  • Ignoring the rule altogether

When none of the first three are good, then I would say that I put this rule into ignore and we skip it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Another option is to raise it with RUFF, and either change the default or add an option to explicitely exclude:

  • properties
  • pytest fixtures
  • methods/functions that override parents with a not-None return type

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 question here is, is this something that just we want, or is this a common pattern in the Python environment? (I checked the original flake8-return, and this plugin does not care about these cases as well)

Copy link
Contributor

@epenet epenet Jul 16, 2024

Choose a reason for hiding this comment

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

Following rebase... can you please keep return None on the properties?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ruff still doesn't like it. Either we change the declared return types to be the same as in the Entity class, or Ruff needs to be adjusted to take cached_property into account as well.

homeassistant/components/neurio_energy/sensor.py Outdated Show resolved Hide resolved
homeassistant/components/samsungtv/bridge.py Outdated Show resolved Hide resolved
homeassistant/components/xiaomi_miio/air_quality.py Outdated Show resolved Hide resolved
tests/components/rainbird/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/rainbird/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/kodi/util.py Outdated Show resolved Hide resolved
tests/components/calendar/test_init.py Outdated Show resolved Hide resolved
homeassistant/util/__init__.py Outdated Show resolved Hide resolved
homeassistant/util/__init__.py Outdated Show resolved Hide resolved
homeassistant/components/input_button/__init__.py Outdated Show resolved Hide resolved
Copy link

github-actions bot commented Jun 8, 2024

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes.
Thank you for your contribution!

@epenet
Copy link
Contributor

epenet commented Jul 10, 2024

@autinerd all the non-property issues should have been cleaned up now in preliminary PRs.

Properties should be ignored when ruff is next updated (0.5.2 ?)
Once that is done, it should be a simple case of updating pyproject.toml - unless new offending code creeps in before then.

@epenet
Copy link
Contributor

epenet commented Jul 15, 2024

@autinerd all the non-property issues should have been cleaned up now in preliminary PRs.

Properties should be ignored when ruff is next updated (0.5.2 ?) Once that is done, it should be a simple case of updating pyproject.toml - unless new offending code creeps in before then.

0.5.2 released... ready for rebase

@autinerd
Copy link
Contributor Author

All changes are removed, but Ruff doesn't like it yet.

@epenet
Copy link
Contributor

epenet commented Jul 20, 2024

All changes are removed, but Ruff doesn't like it yet.

I suggest to open a new issue in ruff, and add no-qa with a link to the ruff issue.

@epenet
Copy link
Contributor

epenet commented Jul 29, 2024

All changes are removed, but Ruff doesn't like it yet.

I suggest to open a new issue in ruff, and add no-qa with a link to the ruff issue.

I couldn't find the issue in ruff... did you open it?
Anyway, I created a fresh PR there for cached_properties: astral-sh/ruff#12563

@epenet
Copy link
Contributor

epenet commented Jul 30, 2024

All changes are removed, but Ruff doesn't like it yet.

I suggest to open a new issue in ruff, and add no-qa with a link to the ruff issue.

I couldn't find the issue in ruff... did you open it? Anyway, I created a fresh PR there for cached_properties: astral-sh/ruff#12563

PR merged on ruff... now waiting for release of 0.5.6

Copy link
Contributor

@epenet epenet left a comment

Choose a reason for hiding this comment

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

LGTM
Ruff has been updated to 0.5.6
I think it's OK to merge when CI completes and it's marked as ready

@autinerd autinerd marked this pull request as ready for review August 2, 2024 19:15
@epenet epenet merged commit d08f4fb into home-assistant:dev Aug 8, 2024
40 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Aug 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants