Spotipy: Getting None object for search "track" api.

[aymather]

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

[Peter-Schorn]

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.

[aymather]

@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?

[Peter-Schorn]

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.

[stephanebruckert]

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

[stephanebruckert]

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

[Peter-Schorn]

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

[stephanebruckert]

@Peter-Schorn fair!

[aymather]

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