mirror of
https://github.com/spotipy-dev/spotipy.git
synced 2026-04-27 00:25:54 +03:00
[GH-ISSUE #626] Getting None object for search "track" api. #375
Labels
No labels
api-bug
bug
dependencies
documentation
duplicate
enhancement
external-ide
headless-mode
implicit-grant-flow
invalid
missing-endpoint
pr-welcome
private-api
pull-request
question
spotipy3
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotipy#375
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @aymather on GitHub (Dec 19, 2020).
Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/626
If I call the following code:
Then I get a response like normal, except one of the track objects in the "tracks" field, is just a
Noneobject. This seems super strange... If it is in the array, shouldn't it be something that they returned?This is the only artist/track name combination that I have found this issue with.
I expect it to return an array of objects where every object... is at least something, not
None.And if it does result in "No Results" for that artist/track name combination, then I expect the "tracks" array to just be empty.
Here is an Image of the "tracks" array with a missing item. I converted the output to javascript just because I was having a weird time viewing it in the python output, but everything is the same, it just says
undefinedinstead ofNone@Peter-Schorn commented on GitHub (Dec 21, 2020):
The Spotify web API does return arrays with null objects in them. Often the reason is because the content is not available in the specified market. This is not a bug. If this is an issue for you, then just filter
Nonevalues out of the array using a list comprehension.@aymather commented on GitHub (Dec 26, 2020):
@Peter-Schorn Does it not make sense to do this inside the spotipy client? I feel like it doesn't make sense to return
Nonewhen I don't even know what theNonething is.Like it would make sense if I at least knew, "this is the track you wanted, but we can't tell you anything more than that because it isn't available in your market."
Is there any situation in which I as the developer, would want a
Noneobject in that response if the item is not available?If not, then I think that step should be done in the Spotipy client.
I have no problem doing that filtering, it just doesn't make sense to me to have to make that check every time I make a request, if nobody actually needs that information. Thoughts?
@Peter-Schorn commented on GitHub (Dec 26, 2020):
That's exactly what Spotify is telling you by returning
None. I don't understand your argument.Yes, if you want to know that the object exists on Spotify, but is not available in the given market. Also, If you're making a request for the tracks in the playlist,
Nonemust be returned for unavailable tracks so that the offset of the available tracks is preserved. If a playlist contains duplicate tracks, or if you want to rearrange the tracks in a playlist, then you have to know the offset of those tracks.You should also know that if you specify a value for the market parameter in the request and the track is not available in the given market, then Spotify will try to find another version of the same track that is available in that market. Read more at the Track Relinking Guide.
@stephanebruckert commented on GitHub (Dec 27, 2020):
@aymather I agree that getting undefined items is a bit unexpected, but I also understand @Peter-Schorn's point about wanting to preserve offsets. Also by default, spotipy aims to return API results "as-is"/without modification, so if it's not a bug on the API side, we shouldn't modify that result.
However we could have an option that would allow to filter out
Nonevalues? That parameter would also allow us to document the fact that tracks can be missing.@stephanebruckert commented on GitHub (Dec 27, 2020):
Wait, that is for the
search()endpoint, notplaylist_tracks(), which means there are no playlists involved. So is there a point worrying about offsets? @aymather could be right@Peter-Schorn commented on GitHub (Dec 27, 2020):
@stephanebruckert Even for other endpoints, like the
search()endpoint, clients may still be relying on theNonevalues to tell them that the content is not available in the requested market. If you do add functionality that filters out these values, then it should be opt-in. Otherwise, you would be making a massive API-breaking change.@stephanebruckert commented on GitHub (Dec 27, 2020):
@Peter-Schorn fair!
@aymather commented on GitHub (Dec 28, 2020):
@Peter-Schorn Sorry let me be more clear in response to:
If instead of it returning
Noneas an object, it returned an object with one field, perhaps atrack_namefield, so that you at least knew what you were offsetting. But with theNoneobject, I don't even know what it is that I'm "not receiving".Because in the search endpoint, you're just searching for "if something exists." But what is helpful about knowing, "something doesn't exist, but you don't know what it is that doesn't exist."? Like what if it's the wrong track that "doesn't exist"?
Idk maybe I'm reaching here... It also isn't THAT big a deal, because now I understand the offset reason. I'm just curious at this point.
@dieser-niko commented on GitHub (Aug 28, 2024):
I'm going to close the issue because it looks like Spotify has filtered out
nullvalues (or at least I didn't receive any with your query). If this still occurs, feel free to reopen or write a comment.