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

Add and corrects typehints in Entity helper & core class #26805

Merged
merged 2 commits into from Sep 24, 2019

Conversation

@frenck
Copy link
Member

commented Sep 21, 2019

Description:

Adds and corrects a bunch of type hints in the Entity class.

Related issue (if applicable): n/a

Pull request with documentation for home-assistant.io (if applicable): n/a

Example entry for configuration.yaml (if applicable): n/a

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist

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. Update and include derived files by running python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.
@frenck frenck requested a review from home-assistant/core as a code owner Sep 21, 2019
@project-bot project-bot bot added this to Needs review in Dev Sep 21, 2019
@pvizeli pvizeli requested a review from scop Sep 23, 2019
@@ -137,28 +137,28 @@ def name(self) -> Optional[str]:
return None

@property
def state(self) -> str:
def state(self) -> Optional[str]:
"""Return the state of the entity."""

This comment has been minimized.

Copy link
@scop

scop Sep 23, 2019

Contributor

Is this really Optional, i.e. is it okay to return None here considering STATE_UNKNOWN exists and is the default? If yes, what's the difference between them?

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Sep 23, 2019

Member

None will be converted to STATE_UNKNOWN when updating state, by the Entity base class. In integrations we use None to represent unknown state.

This comment has been minimized.

Copy link
@scop

scop Sep 23, 2019

Contributor

Sounds like a cleanup opportunity to me, would be better to have just one representation for unknown state everywhere. That's not a problem with this PR though.

This comment has been minimized.

Copy link
@frenck

frenck Sep 23, 2019

Author Member

@scop I agree actually... Maybe revert it and work towards changing the codebase?
The real shocker for me personally, it the fact it has to be a string... We throw everything at it from all our integrations (still handled, nevertheless, not intended).

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Sep 23, 2019

Member

It's nice to not have to import UNKNOWN_STATE in every platform to represent unknown state. If we can make it more consistent in another way, that would be interesting.

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Sep 23, 2019

Member

The states to be saved are taken from the state machine, so we restore the state from the state machine. So you're right that that could mean a complication somewhere, if it's not handled by the restore state logic.

This comment has been minimized.

Copy link
@balloob

balloob Sep 23, 2019

Member

I am all in favor of making it explicit and having it be str and setting STATE_UNKNOWN in the constructor if passed in state is None.

This comment has been minimized.

Copy link
@balloob

balloob Sep 23, 2019

Member

ooh I realize now that this is helper/entity.py, not core.py.

We convert it to a string and even with correct typing, i want to keep it that way, because I do not trust integrations, especially custom components. This will not be caught with just type checks.

This comment has been minimized.

Copy link
@balloob

balloob Sep 23, 2019

Member

So since we cast it to a string, we could eh, do Any?

This comment has been minimized.

Copy link
@frenck

frenck Sep 24, 2019

Author Member

I've applied a suggestion I got from @pvizeli:

Union[None, str, int, float]

Which, should cover our grounds for the entity helper. Based on the comments here, I've also adjusted the type hints for core entity. The discussion clearly settled on the state in the core is a string, so I've adjusted the core entity to reflect that.
See: 4ca3f7b

@frenck frenck changed the title Add and corrects typehints in Entity class Add and corrects typehints in Entity helper & core class Sep 24, 2019
Dev automation moved this from Needs review to Reviewer approved Sep 24, 2019
@balloob balloob merged commit 6f9ccb5 into dev Sep 24, 2019
7 of 9 checks passed
7 of 9 checks passed
CI Build #20190924.24 failed
Details
CI (FullCheck Pylint) FullCheck Pylint failed
Details
CI (FullCheck Mypy) FullCheck Mypy succeeded
Details
CI (Overview CheckFormat) Overview CheckFormat succeeded
Details
CI (Overview Lint) Overview Lint succeeded
Details
CI (Overview Validate) Overview Validate succeeded
Details
CI (Tests PyTest Python36) Tests PyTest Python36 succeeded
Details
CI (Tests PyTest Python37) Tests PyTest Python37 succeeded
Details
cla-bot Everyone involved has signed the CLA
Dev automation moved this from Reviewer approved to Done Sep 24, 2019
@delete-merged-branch delete-merged-branch bot deleted the frenck-2019-0197 branch Sep 24, 2019
@lock lock bot locked and limited conversation to collaborators Sep 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Dev
  
Done
5 participants
You can’t perform that action at this time.