@ChristopherRabotin, @adventures91, @kipe, @weiyoung-zhou, @georgijd

Any feedback?

Should I always return a list of ResultSets? What I am doing right now is that I am returning a list only if there are more than 1 results.

Let me know if you don't wish to be included in those discussions.

I do like the changes in general, makes the code more pythonic.
Especially the filtering by tags seems more logical by using this kind of structure.

It would be more logical to me, if one query would return a single ResultSet and multiple queries a list of ResultSets.

On the other hand, returning a list always would be constant, but does raise the question on how often is this feature used. And even if it is, the programmer should know he's running multiple queries and should expect multiple results -> knows to expect a list of ResultSets instead of a single ResultSet.

It would be more logical to me, if one query would return a single ResultSet and multiple queries a list of ResultSets.

That's exactly what it does in my PR. If you make multiple queries (separated by ;) in a single client.query() call, you will get a list of ResultSets

but does raise the question on how often is this feature used.

Indeed. Most users will have to get the first element of the list all the time. It would be quite annoying. I would also like to avoid breaking the API so this is why chose not to return a list.

I second @kipe's opinion on the filtering :) That way the ResultSet object becomes more flexible and we can easily add more filter parameters in the future. As for the multiple queries result type, what makes most sense to me is that a single query should return a single ResultSet object and multiple queries should return a list of ResultSet objects. From developer's perspective, it's really frustrating to always use expressions like rs[0] to get the data you need when most of the time you execute a single query. It pollutes the code and it's prone to errors.

Thank you for the feedback.