Using classes to determine result types

[scj643]

The api can get confusing and making results be just straight up dictionaries means keeping track of stuff is hard. I purpose using different classes for different result types.

Like songs would be it's own class that the object itself can be passed to get the stream url.

[simon-weber]

It's a reasonable idea, though I don't think it's something I'm likely to get to any time soon. And unless we want to make a breaking change, we'd need to keep the dict interface on whatever we moved to.

Is the pain point specifically around being able to check the type of a result (eg playlist vs station, etc)? It'd be relatively straightforward to wrap the dicts and add that.

[thebigmunch]

The last part of your comment sounds more like turning everything into an object, rather than just search results. That's what would be required to provide a consistent API. This is something that I've done in an unreleased experiment, similar to the API and implementation of github3.py. It's not exactly easy for the author there, and the GitHub API is a well-documented, consistent REST API. I found many more pain points and shelved my experiment in favor of other things. It's something that I might poke back around to in the future. But, like Simon, it's unlikely to be soon, if ever.

[scj643]

Couldn't we just provide a dict attribute to all the classes so that results would still be compatible with code that expects dicts.

[simon-weber]

Yup, that's what I was picturing in my earlier comment. I'm not sure what beyond that is needed to address the pain point from the OP, though.

[scj643]

Another solution would be a key standard to all results that is a string with the key type