-
Notifications
You must be signed in to change notification settings - Fork 24
More ruff and warning cleanup #356
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
base: master
Are you sure you want to change the base?
Changes from 4 commits
dd1fddb
1613b52
0abd482
2f7b7dd
4700b77
0c44407
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -30,6 +30,7 @@ async def async_get_config_entry_diagnostics( | |
| return await _get_diagnostics(hass, config_entry) | ||
| except Exception: | ||
| _LOGGER.exception("Error getting diagnostics") | ||
| return {} | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's correct behavior here? Is it to return nothing like everything is ok, or would a more correct approach be to escalate the error to HA? What does other integrations do?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking a bit more thoroughly at it, I don't see how we can ever reach this line of code anyway. Pretty much all of |
||
|
|
||
|
|
||
| async def async_get_device_diagnostics( | ||
|
|
@@ -40,6 +41,7 @@ async def async_get_device_diagnostics( | |
| return await _get_diagnostics(hass, config_entry) | ||
| except Exception: | ||
| _LOGGER.exception("Error getting diagnostics for device %s", device.id) | ||
| return {} | ||
|
|
||
|
|
||
| async def _get_diagnostics( | ||
|
|
@@ -80,23 +82,24 @@ def add_failure(err: Exception) -> None: | |
| try: | ||
| api = out.setdefault("api", {}) | ||
|
|
||
| async def request(url: str) -> Any: | ||
| async def request(url: str) -> dict | list: | ||
| """Make an API request and return the result.""" | ||
| try: | ||
| result = await zaptec.request(url) | ||
| if not isinstance(result, (dict, list)): | ||
| return { | ||
| "type error": f"Expected dict, got type {type(result).__name__}, value {result}", | ||
| "type error": f"Expected dict or list, got type {type(result).__name__}, value {result}", # noqa: E501 | ||
| } | ||
| return result | ||
| except Exception as err: | ||
| return { | ||
| "exception": type(err).__name__, | ||
| "err": str(err), | ||
| "tb": list(traceback.format_exc().splitlines()), | ||
| } | ||
| else: | ||
| return result | ||
|
Comment on lines
+99
to
+100
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why this change? I find the way it was more readable than this change. Is there a formatting recommendation behind this one?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm inclined to agree, but https://docs.astral.sh/ruff/rules/try-consider-else/ doesn't, and it does seem to be a convention that is in use in core 🤷 |
||
|
|
||
| def add(url, obj, ctx=None) -> None: | ||
| def add(url: str, obj: dict | list, ctx: str = "") -> None: | ||
| api[redact(url, ctx=ctx)] = redact(obj, ctx=ctx) | ||
|
|
||
| data = await request(url := "installation") | ||
|
|
@@ -109,8 +112,9 @@ def add(url, obj, ctx=None) -> None: | |
|
|
||
| for circuit in data.get("Circuits", []): | ||
| add(f"circuits/{circuit['Id']}", circuit, ctx="circuit") | ||
| for charger in circuit.get("Chargers", []): | ||
| charger_in_circuits_ids.append(charger["Id"]) | ||
| charger_in_circuits_ids.extend( | ||
| charger["Id"] for charger in circuit.get("Chargers", []) | ||
| ) | ||
|
|
||
| add(url, data, ctx="hierarchy") | ||
|
|
||
|
|
@@ -126,7 +130,7 @@ def add(url, obj, ctx=None) -> None: | |
| add(url, data, ctx="charger") | ||
|
|
||
| data = await request(url := f"chargers/{charger_id}/state") | ||
| redact.redact_statelist(data, ctx="state") | ||
| data = redact.redact_statelist(data, ctx="state") | ||
steinmn marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| add(url, data, ctx="state") | ||
|
|
||
| except Exception as err: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm not mistaken, doesn't this result in a diamond inheritance? Does this have any practical effects in this usage? I've been taught to avoid them like the plague.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll be honest, I'd never heard of diamond inheritance before. Having said that, is this really any different from
class ZaptecBinarySensor(ZaptecBaseEntity, BinarySensorEntity):a couple of lines above this? Both inherit from the Entity class (if you dig down a bit). Also, these particular classes only add (non-overlapping) variables, so there's no ambiguity.
This was done to avoid the warning
Argument of type "Iterable[EntityDescription]" cannot be assigned to parameter "descriptions" of type "Iterable[ZaptecEntityDescription]" in function "create_entities_from_descriptions". Unsure about the practical effects.