[GH-ISSUE #626] Getting None object for search "track" api. #375

Closed
opened 2026-02-27 23:22:17 +03:00 by kerem · 9 comments
Owner

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:

artist = 'Joe Arroyo Y La Verdad'
track = 'Ban Ban'
q = 'track:{} artist:{}'.format(track, artist)

results = sp.search(q=q, type = "track", limit = 20)

Then I get a response like normal, except one of the track objects in the "tracks" field, is just a None object. 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 undefined instead of None

Screen Shot 2020-12-19 at 10 33 19 AM

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: ``` artist = 'Joe Arroyo Y La Verdad' track = 'Ban Ban' q = 'track:{} artist:{}'.format(track, artist) results = sp.search(q=q, type = "track", limit = 20) ``` Then I get a response like normal, except one of the track objects in the "tracks" field, is just a `None` object. 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 `undefined` instead of `None` ![Screen Shot 2020-12-19 at 10 33 19 AM](https://user-images.githubusercontent.com/41848756/102694284-a2d33900-41e5-11eb-9c79-35ee2f9fe251.png)
kerem 2026-02-27 23:22:17 +03:00
Author
Owner

@Peter-Schorn commented on GitHub (Dec 21, 2020):

If it is in the array, shouldn't it be something that they returned?

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 None values out of the array using a list comprehension.

<!-- gh-comment-id:748854158 --> @Peter-Schorn commented on GitHub (Dec 21, 2020): > If it is in the array, shouldn't it be something that they returned? 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 `None` values out of the array using a list comprehension.
Author
Owner

@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 None when I don't even know what the None thing 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 None object 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?

<!-- gh-comment-id:751386576 --> @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 `None` when I don't even know what the `None` thing 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 `None` object 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?
Author
Owner

@Peter-Schorn commented on GitHub (Dec 26, 2020):

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."

That's exactly what Spotify is telling you by returning None. I don't understand your argument.

Is there any situation in which I as the developer, would want a None object in that response if the item is not available?

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, None must 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.

<!-- gh-comment-id:751393161 --> @Peter-Schorn commented on GitHub (Dec 26, 2020): > 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." That's exactly what Spotify is telling you by returning `None`. I don't understand your argument. > Is there any situation in which I as the developer, would want a None object in that response if the item is not available? 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, `None` must 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](https://developer.spotify.com/documentation/general/guides/track-relinking-guide/).
Author
Owner

@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 None values? That parameter would also allow us to document the fact that tracks can be missing.

<!-- gh-comment-id:751482817 --> @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 `None` values? That parameter would also allow us to document the fact that tracks can be missing.
Author
Owner

@stephanebruckert commented on GitHub (Dec 27, 2020):

Wait, that is for the search() endpoint, not playlist_tracks(), which means there are no playlists involved. So is there a point worrying about offsets? @aymather could be right

<!-- gh-comment-id:751488455 --> @stephanebruckert commented on GitHub (Dec 27, 2020): Wait, that is for the `search()` endpoint, not `playlist_tracks()`, which means there are no playlists involved. So is there a point worrying about offsets? @aymather could be right
Author
Owner

@Peter-Schorn commented on GitHub (Dec 27, 2020):

@stephanebruckert Even for other endpoints, like the search() endpoint, clients may still be relying on the None values 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.

<!-- gh-comment-id:751524977 --> @Peter-Schorn commented on GitHub (Dec 27, 2020): @stephanebruckert Even for other endpoints, like the `search()` endpoint, clients may still be relying on the `None` values 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.
Author
Owner

@stephanebruckert commented on GitHub (Dec 27, 2020):

@Peter-Schorn fair!

<!-- gh-comment-id:751531045 --> @stephanebruckert commented on GitHub (Dec 27, 2020): @Peter-Schorn fair!
Author
Owner

@aymather commented on GitHub (Dec 28, 2020):

@Peter-Schorn Sorry let me be more clear in response to:

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."

That's exactly what Spotify is telling you by returning None. I don't understand your argument.

If instead of it returning None as an object, it returned an object with one field, perhaps a track_name field, so that you at least knew what you were offsetting. But with the None object, 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.

<!-- gh-comment-id:751781912 --> @aymather commented on GitHub (Dec 28, 2020): @Peter-Schorn Sorry let me be more clear in response to: > 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." > That's exactly what Spotify is telling you by returning None. I don't understand your argument. If instead of it returning `None` as an object, it returned an object with one field, perhaps a `track_name` field, so that you at least knew what you were offsetting. But with the `None` object, 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.
Author
Owner

@dieser-niko commented on GitHub (Aug 28, 2024):

I'm going to close the issue because it looks like Spotify has filtered out null values (or at least I didn't receive any with your query). If this still occurs, feel free to reopen or write a comment.

<!-- gh-comment-id:2314919044 --> @dieser-niko commented on GitHub (Aug 28, 2024): I'm going to close the issue because it looks like Spotify has filtered out `null` values (or at least I didn't receive any with your query). If this still occurs, feel free to reopen or write a comment.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/spotipy#375
No description provided.