Convenience query functions for Python

[James Aylett]

The following code extends the Database object to make Enquire and Query operation easier. We shouldn't put it in the bindings, but it would be useful to document somewhere (or possibly, although not likely, add as similar convenience functions in core).

def database_enquire(self, querystring, flags=0, language=None, strategy=None, \ queryparser=None):

enq = Enquire(self) if queryparser==None:

queryparser = QueryParser() if language!=None:

queryparser.set_stemmer(Stem(language)) if strategy==None:

strategy = QueryParser.STEM_SOME

if strategy==None:

queryparser.set_stemming_strategy(QueryParser.STEM_NONE)

else:

queryparser.set_stemming_strategy(strategy)

q = queryparser.parse_query(querystring, flags) enq.set_query(q) return enq

def database_query(self, querystring, first=0, maxitems=10, flags=0, language=N\ one, strategy=None, queryparser=None):

enq = self.enquire(querystring, flags, language, strategy, queryparser) return enq.get_mset(first, maxitems)

Database.enquire = database_enquire Database.query = database_query

[Olly Betts]

Search::Xapian has a couple of methods along similar lines. In general I'm not enthusiastic about them, though I guess they do fit with the Perl TMTOWTDI philosophy (which Python rather rejects I believe...)

In cases where there's a simple set of defaults which are very commonly used I can see an argument for providing a shortcut, but adding methods which take 5 or 7 parameters in place of creating an object and setting attributes on it seems a mistake. We consciously made the design choice to use an object here rather than have methods which take lots of parameters, and offering alternatives to that just seems to increase the size of the API without offering enough of a gain.

Adding methods like these also mean that if you're using Database.enquire and then decide you want to sort your results by value, you need to rewrite a lot of code rather than just add a method call. A version of Database.enquire which covered every possible setting would be hard to work with (and increasingly so with time as more methods were added), even if we supported named parameters.

I don't see that it makes sense to not apply this, yet document it. If we document it, that suggests we think it's a good idea, and users will justifiably wonder why they are forced to implement it for themselves.

So I'm afraid I'm going to close this as WONTFIX. Sorry.

[James Aylett]

We don't have to black and white, and put exactly that code in documentation. We could, for instance, have an example that shows that functionality straight in main(). We get messages to the list periodically which a more featured example would probably obviate; simplesearch.py at the moment doesn't use the QueryParser at all. (It shouldn't, but something probably should.)

In any case, my primary intention of sticking it into bugzilla was so we wouldn't lose it, not so we would act on it immediately.

Changed component to Examples, which is closer to my intent.