Minor improvements to deezer plugin typing. #5814
Conversation
|
Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry. |
There was a problem hiding this comment.
Pull Request Overview
This pull request enhances the Deezer plugin by adding and refining type hints to improve code maintainability and prepare for an upcoming migration.
- Updated function signatures with type hints (e.g. commands, track_for_id, _get_track, _search_api).
- Re-ordered and consolidated API URLs and fetch_data implementation.
- Adjusted imports and type annotations across both beetsplug/deezer.py and beets/plugins.py.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| beetsplug/deezer.py | Added type hints, updated function parameters/docstrings, and moved API URL definitions. |
| beets/plugins.py | Updated _search_api type hints for query_type using Literal. |
Comments suppressed due to low confidence (1)
beetsplug/deezer.py:149
- The docstring for track_for_id still references a track_data parameter that was removed from the function signature. Please update the documentation to reflect the current parameters.
:param track_data: (Optional) Simplified track object dict. May be provided instead of ``track_id`` to avoid unnecessary API calls.
|
|
||
| class DeezerPlugin(MetadataSourcePlugin, BeetsPlugin): | ||
|
|
||
| class DeezerPlugin(MetadataSourcePlugin[Response], BeetsPlugin): |
There was a problem hiding this comment.
Shouldn't we define a deezer-specific Response?
There was a problem hiding this comment.
Optimally yes! Adding one should be relative straight forward, this Response here only defines an id attribute.
I did not want to create an deezer account to look at the api documentation tbh. But maybe someone else wants to tackle this.
| @@ -737,7 +738,7 @@ def track_url(self) -> str: | |||
| @abc.abstractmethod | |||
| def _search_api( | |||
| self, | |||
| query_type: str, | |||
| query_type: Literal["album", "track"], | |||
There was a problem hiding this comment.
I'd suggest defining
QueryType = Literal["album", "track"]And import it in beetsplug/deezer.py instead of defining it in multiple places
There was a problem hiding this comment.
Yeah something alike would be preferable, I might revisit it once we merge the metadata plugin PR.
There was a problem hiding this comment.
Also I just noticed that the deezer api can take other query types, thus defining it globally might intertwine the types more the necessary. E.g. for deezer the complete type-hint would be:
Literal[
"album",
"track",
"artist",
"history",
"playlist",
"podcast",
"radio",
"user",
],There was a problem hiding this comment.
I see. I don't think the interface/abstract definition should be coupled to any specific child/plugin implementation.
We know that this method is only ever called with values album and track, so I think we should just add these two in the type definition.
There was a problem hiding this comment.
For the main definition that is the case i.e. in the MetadatasourcePlugin the method only supports album and track.
It should be fine if the specific plugins support more than we need from the core perspective. Just added it here to indicate that (in theory) the deezer api supports these endpoint and removed the comment regarding the endpoints.
Description
Added some more typehints to deezer plugin.
I know, it is properly not used much and we don't even have test for the deezer plugin but I want to make this a bit more maintainable, mainly to prepare for #5787 and make migration a bit easier.