Well, first() does catch the exception that occurs when you try to access the 0th element of an empty result set, which seems like an abstraction which could at least conceivably be useful.

Additionally, since calling __iter__() on a ViewResults object (such as by iterating over it in a for loop without calling all()) returns a generator that lazily instantiates Python objects from the rows of the CouchDB JSON response as you request them, and using list slice notation on the ViewResults object also doesn't instantiate anything, using .all() within the wrapper method and returning a list prevents the caller from taking advantage of the underlying generator to program in a way that consumes less memory and has a lower initial wait time for result objects to start being yielded, and it forces them to instantiate all the objects even if they want only a few.

view_results.count() also returns the number of results without having to instantiate them all.

Regardless, perhaps useful abstractions will be added to couchdbkit in the future, or we might want to make a subclass in the future with abstractions we find useful?

So, in sum, I'd say there are actually pretty compelling reasons for never putting all() inside the query method.

@yedi