This file is indexed.

/usr/share/doc/python-xapian/index.html is in python-xapian 1.2.8-1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
<html><head><title>Python bindings for Xapian</title></head>
<body>
<h1>Python bindings for Xapian</h1>

<p>
The Python bindings for Xapian are packaged in the <code>xapian</code> module,
and largely follow the C++ API, with the following differences and
additions. Python strings and lists, etc., are converted automatically
in the bindings, so generally it should just work as expected.
</p>

<p>
The <code>examples</code> subdirectory contains examples showing how to use the
Python bindings based on the simple examples from <code>xapian-examples</code>:
<a href="examples/simpleindex.py">simpleindex.py</a>,
<a href="examples/simplesearch.py">simplesearch.py</a>,
<a href="examples/simpleexpand.py">simpleexpand.py</a>.
There's also 
<a href="examples/simplematchdecider.py">simplematchdecider.py</a>
which shows how to define a MatchDecider in Python.
</p>

<p>
The Python bindings come with a test suite, consisting of two test files:
<code>smoketest.py</code> and <code>pythontest.py</code>. These are run by the
"<code>make check</code>" command, or may be run manually.  By default, they
will display the names of any tests which failed, and then display a count of
tests which run and which failed.  The verbosity may be increased by setting
the "<code>VERBOSE</code>" environment variable: a value of 1 will display
detailed information about failures, and a value of 2 will display further
information about the progress of tests.
</p>

<h2>Exceptions</h2>

<p>
   Xapian exceptions are translated into Python exceptions with the same names
   and inheritance hierarchy as the C++ exception classes.  The base class of
   all Xapian exceptions is the <code>xapian.Error</code> class, and this in
   turn is a child of the standard python <code>exceptions.Exception</code>
   class.
</p>
<p>
   This means that programs can trap all xapian exceptions using "<code>except
   xapian.Error</code>", and can trap all exceptions which don't indicate that
   the program should terminate using "<code>except Exception</code>".
</p>

<h2>Unicode</h2>

<p>
   The xapian Python bindings accept unicode strings as well as simple strings
   (ie, "str" type strings) at all places in the API which accept string data.
   Any unicode strings supplied will automatically be translated into UTF-8
   simple strings before being passed to the Xapian core.  The Xapian core is
   largely agnostic about character encoding, but in those places where it does
   process data in a character encoding dependent way it assumes that the data
   is in UTF-8.  The Xapian Python bindings always return string data as simple
   strings.
</p>
<p>
   Therefore, in order to avoid issues with character encodings, you should
   always pass text data to Xapian as unicode strings, or UTF-8 encoded simple
   strings.  There is, however, no requirement for simple strings passed into
   Xapian to be valid UTF-8 encoded strings, unless they are being passed to a
   text processing routine (such as the query parser, or the stemming
   algorithms).  For example, it is perfectly valid to pass arbitrary binary
   data in a simple string to the <code>xapian.Document.set_data()</code>
   method.
</p>
<p>
   It is often useful to normalise unicode data before passing it to Xapian -
   Xapian currently has no built-in support for normalising unicode
   representations of data.  The standard python module
   "<code>unicodedata</code>" provides support for normalising unicode: you
   probably want the "<code>NFKC</code>" normalisation scheme: in other words,
   use something like
</p>
<pre>
   unicodedata.normalize('NFKC', u'foo')
</pre>
<p>
   to normalise the string "foo" before passing it to Xapian.
</p>

<h2>Iterators</h2>

<p>
The iterator classes in the Xapian C++ API are wrapped in a "Pythonic" style.
The following are supported (where marked as default iterator, it means
<code>__iter__()</code> does the right
thing so you can for instance use <code>for term in document</code> to
iterate over terms in a Document object):
</p>

<table title="Python iterators">
<thead><td>Class</td><td>Method</td><td>Equivalent to</td><td>Iterator type</td></thead>
<tr><td><code>MSet</code></td><td>default iterator</td><td><code>begin()</code></td><td><code>MSetIter</code></td></tr>
<tr><td><code>ESet</code></td><td>default iterator</td><td><code>begin()</code></td><td><code>ESetIter</code></td></tr>
<tr><td><code>Enquire</code></td><td><code>matching_terms()</code></td><td><code>get_matching_terms_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Query</code></td><td>default iterator</td><td><code>get_terms_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>allterms()</code> (also as default iterator)</td><td><code>allterms_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>postlist(tname)</code></td><td><code>postlist_begin(tname)</code></td><td><code>PostingIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>termlist(docid)</code></td><td><code>termlist_begin(docid)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>positionlist(docid, tname)</code></td><td><code>positionlist_begin(docid, tname)</code></td><td><code>PositionIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>metadata_keys(prefix)</code></td><td><code>metadata_keys(prefix)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>spellings()</code></td><td><code>spellings_begin(term)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>synonyms(term)</code></td><td><code>synonyms_begin(term)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Database</code></td><td><code>synonym_keys(prefix)</code></td><td><code>synonym_keys_begin(prefix)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>Document</code></td><td><code>values()</code></td><td><code>values_begin()</code></td><td><code>ValueIter</code></td></tr>
<tr><td><code>Document</code></td><td><code>termlist()</code> (also as default iterator)</td><td><code>termlist_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>QueryParser</code></td><td><code>stoplist()</code></td><td><code>stoplist_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>QueryParser</code></td><td><code>unstemlist(tname)</code></td><td><code>unstem_begin(tname)</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>ValueCountMatchSpy</code></td><td><code>values()</code></td><td><code>values_begin()</code></td><td><code>TermIter</code></td></tr>
<tr><td><code>ValueCountMatchSpy</code></td><td><code>top_values()</code></td><td><code>top_values_begin()</code></td><td><code>TermIter</code></td></tr>
</table>

<p>
The pythonic iterators generally return Python objects, with properties
available as attribute values, with lazy evaluation where appropriate.  An
exception is the <code>PositionIter</code> object returned by
<code>Database.positionlist</code>, which returns an integer.
</p>

<p>
The lazy evaluation is mainly transparent, but does become visible in one situation: if you keep an object returned by an iterator, without evaluating its properties to force the lazy evaluation to happen, and then move the iterator forward, the object may no longer be able to efficiently perform the lazy evaluation.  In this situation, an exception will be raised indicating that the information requested wasn't available.  This will only happen for a few of the properties - most are either not evaluated lazily (because the underlying Xapian implementation doesn't evaluate them lazily, so there's no advantage in lazy evaluation), or can be accessed even after the iterator has moved.  The simplest work around is simply to evaluate any properties you wish to use which are affected by this before moving the iterator.  The complete set of iterator properties affected by this is:
</p>

<ul>
<li>
Database.allterms (also accessible as Database.__iter__): <b>termfreq</b>
</li><li>
Database.termlist: <b>termfreq</b> and <b>positer</b>
</li><li>
Document.termlist (also accessible as Document.__iter__): <b>termfreq</b> and <b>positer</b>
</li><li>
Database.postlist: <b>positer</b>
</li>
</ul>

<p>
In older releases, the pythonic iterators returned lists representing the
appropriate item when their <code>next()</code> method was called.  These were
removed in Xapian 1.1.0.
</p>

<h2>Non-Pythonic Iterators</h2>

<p>
Before the pythonic iterator wrappers were added, the python bindings provided
thin wrappers around the C++ iterators.  However, these iterators don't behave
like most iterators do in Python, so the pythonic iterators were implemented to
replace them.  The non-pythonic iterators are still available to allow existing
code to continue to work, but they're now deprecated and we plan to remove them
in Xapian 1.3.0.  The documentation below is provided to aid migration away from
them.
</p>

<p>
   All non-pythonic iterators support <code>next()</code> and
   <code>equals()</code> methods
   to move through and test iterators (as for all language bindings).
   MSetIterator and ESetIterator also support <code>prev()</code>.
   Python-wrapped iterators also support direct comparison, so something like:
</p>

<pre>
   m=mset.begin()
   while m!=mset.end():
     # do something
     m.next()
</pre>

<p>
   C++ iterators are often dereferenced to get information, eg
   <code>(*it)</code>. With Python these are all mapped to named methods, as
   follows:
</p>

<table title="Iterator deferencing methods">
<thead><td>Iterator</td><td>Dereferencing method</td></thead>
<tr><td>PositionIterator</td>	<td><code>get_termpos()</code></td></tr>
<tr><td>PostingIterator</td>	<td><code>get_docid()</code></td></tr>
<tr><td>TermIterator</td>	<td><code>get_term()</code></td></tr>
<tr><td>ValueIterator</td>	<td><code>get_value()</code></td></tr>
<tr><td>MSetIterator</td>	<td><code>get_docid()</code></td></tr>
<tr><td>ESetIterator</td>	<td><code>get_term()</code></td></tr>
</table>

<p>
   Other methods, such as <code>MSetIterator.get_document()</code>, are
   available unchanged.
</p>

<h2>MSet</h2>

<p>
   MSet objects have some additional methods to simplify access (these
   work using the C++ array dereferencing):
</p>

<table title="MSet additional methods">
<thead><td>Method name</td><td>Explanation</td></thead>
<tr><td><code>get_hit(index)</code></td><td>returns MSetItem at index</td></tr>
<tr><td><code>get_document_percentage(index)</code></td><td><code>convert_to_percent(get_hit(index))</code></td></tr>
<tr><td><code>get_document(index)</code></td><td><code>get_hit(index).get_document()</code></td></tr>
<tr><td><code>get_docid(index)</code></td><td><code>get_hit(index).get_docid()</code></td></tr>
</table>

<p>
Additionally, the MSet has a property, <code>mset.items</code>, which returns a
list of tuples representing the MSet.  This is now deprecated - please use the
property API instead (it works in Xapian 1.0.x too).  The tuple members and the
equivalent property names are as follows:
</p>

<table title="MSet.items member members">
<thead><td>Index</td><td>Property name</td><td>Contents</td></thead>
<tr><td><code>xapian.MSET_DID</code></td><td>docid</td><td>Document id</td></tr>
<tr><td><code>xapian.MSET_WT</code></td><td>weight</td><td>Weight</td></tr>
<tr><td><code>xapian.MSET_RANK</code></td><td>rank</td><td>Rank</td></tr>
<tr><td><code>xapian.MSET_PERCENT</code></td><td>percent</td><td>Percentage weight</td></tr>
<tr><td><code><i>xapian.MSET_DOCUMENT</i></code></td><td>document</td><td>Document object (Note: this member of the tuple was never actually set!)</td></tr>
</table>

<p>
Two MSet objects are equal if they have the same number and maximum possible
number of members, and if every document member of the first MSet exists at the
same index in the second MSet, with the same weight.
</p>

<h2>ESet</h2>

<p>
The ESet has a property, <code>eset.items</code>, which returns a list of
tuples representing the ESet.  This is now deprecated - please use the
property API instead (it works in Xapian 1.0.x too).  The tuple members and the
equivalent property names are as follows:
</p>

<table title="ESet.items member members">
<thead><td>Index</td><td>Property name</td><td>Contents</td></thead>
<tr><td><code>xapian.ESET_TNAME</code></td><td>term</td><td>Term name</td></tr>
<tr><td><code>xapian.ESET_WT</code></td><td>weight</td><td>Weight</td></tr>
</table>

<h2>Non-Class Functions</h2>

<p>The C++ API contains a few non-class functions (the Database factory
functions, and some functions reporting version information), which are
wrapped like so for Python:
<ul>
<ul>
<li> <code>Xapian::version_string()</code> is wrapped as <code>xapian.version_string()</code>
<li> <code>Xapian::major_version()</code> is wrapped as <code>xapian.major_version()</code>
<li> <code>Xapian::minor_version()</code> is wrapped as <code>xapian.minor_version()</code>
<li> <code>Xapian::revision()</code> is wrapped as <code>xapian.revision()</code>
</ul>
<ul>
<li> <code>Xapian::Auto::open_stub()</code> is wrapped as <code>xapian.open_stub()</code>
<li> <code>Xapian::Brass::open()</code> is wrapped as <code>xapian.brass_open()</code>
<li> <code>Xapian::Chert::open()</code> is wrapped as <code>xapian.chert_open()</code>
<li> <code>Xapian::Flint::open()</code> is wrapped as <code>xapian.flint_open()</code>
<li> <code>Xapian::InMemory::open()</code> is wrapped as <code>xapian.inmemory_open()</code>
<li> <code>Xapian::Remote::open()</code> is wrapped as <code>xapian.remote_open()</code> (both
the TCP and "program" versions are wrapped - the SWIG wrapper checks the parameter list to
decide which to call).
<li> <code>Xapian::Remote::open_writable()</code> is wrapped as <code>xapian.remote_open_writable()</code> (both
the TCP and "program" versions are wrapped - the SWIG wrapper checks the parameter list to
decide which to call).
</ul>
</ul>

<h2>Query</h2>

<p>
   In C++ there's a Xapian::Query constructor which takes a query operator and
   start/end iterators specifying a number of terms or queries, plus an optional
   parameter.  In Python, this is wrapped to accept any Python sequence (for
   example a list or tuple) to give the terms/queries, and you can specify
   a mixture of terms and queries if you wish.  For example:
</p>

<pre>
   subq = xapian.Query(xapian.Query.OP_AND, "hello", "world")
   q = xapian.Query(xapian.Query.OP_AND, [subq, "foo", xapian.Query("bar", 2)])
</pre>

<h3>MatchAll and MatchNothing</h3>

<p>
As of 1.1.1, these are wrapped as <code>xapian.Query.MatchAll</code> and
<code>xapian.Query.MatchNothing</code>.
</p>

<h2>MatchDecider</h2>

<p>
Custom MatchDeciders can be created in Python; simply subclass
xapian.MatchDecider, ensure you call the super-constructor, and define a
__call__ method that will do the work. The simplest example (which does nothing
useful) would be as follows:
</p>

<pre>
class mymatchdecider(xapian.MatchDecider):
  def __init__(self):
    xapian.MatchDecider.__init__(self)

  def __call__(self, doc):
    return 1
</pre>

<h2>ValueRangeProcessors</h2>

<p>
The ValueRangeProcessor class (and its subclasses) provide an operator() method
(which is exposed in python as a __call__() method, making the class instances
into callables).  This method checks whether a beginning and end of a range are
in a format understood by the ValueRangeProcessor, and if so, converts the
beginning and end into strings which sort appropriately.  ValueRangeProcessors
can be defined in python (and then passed to the QueryParser), or there are
several default built-in ones which can be used.
</p>

<p>
Unfortunately, in C++ the operator() method takes two std::string arguments by
reference, and returns values by modifying these arguments.  This is not
possible in Python, since strings are immutable objects.  Instead, in the
Python implementation, when the __call__ method is called, the resulting values
of these arguments are returned as part of a tuple.  The operator() method in
C++ returns a value number; the return value of __call__ in python consists of
a 3-tuple starting with this value number, followed by the returned "begin"
value, followed by the returned "end" value.  For example:
</p>

<pre>
    vrp = xapian.NumberValueRangeProcessor(0, '$', True)
    a = '$10'
    b = '20'
    slot, a, b = vrp(a, b)
</pre>

<p>
Additionally, a ValueRangeProcessor may be implemented in Python.  The Python
implementation should override the __call__() method with its own
implementation, and, again, since it cannot return values by reference, it
should return a tuple of (value number, begin, end).  For example:
</p>

<pre>
    class MyVRP(xapian.ValueRangeProcessor):
        def __init__(self):
            xapian.ValueRangeProcessor.__init__(self)
        def __call__(self, begin, end):
            return (7, "A"+begin, "B"+end)
</pre>


<h2>Apache and mod_python/mod_wsgi</h2>

<p>
By default, both mod_python and mod_wsgi use a separate sub-interpreter for
each application.  However, Python's sub-interpreter support is incompatible
with the simplified GIL state API which SWIG-generated Python bindings use
by default.  So to avoid deadlocks, you need to tell mod_python and mod_wsgi
to run applications which use Xapian in the main interpreter as detailed below.
</p>

<p>
This restriction could be removed - the details are in Xapian's bugtracker - see
<a href="http://trac.xapian.org/ticket/364">ticket #364</a> for details of
what needs doing.
</p>

<h3 id="mod_python">mod_python</h3>

<p>
You need to set this option in the Apache configuration section for all
mod_python scripts which use Xapian:
</p>
<pre>PythonInterpreter main_interpreter
</pre>

<p>
You may also need to use Python &gt;= 2.4 (due to <a
href="http://issues.apache.org/jira/browse/MODPYTHON-217">problems in Python
2.3 with the APIs the code uses</a>).
</p>

<h3 id="mod_wsgi">mod_wsgi</h3>

<p>
You need to set the
<a href="http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIApplicationGroup">WSGIApplicationGroup option</a> like so:
</p>

<pre>WSGIApplicationGroup %{GLOBAL}
</pre>

<p>
The mod_wsgi documentation 
<a href="http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API">also discusses this issue</a>.
</p>

<address>
Last updated $Date: 2011-02-21 14:48:22 +0000 (Mon, 21 Feb 2011) $
</address>
</body>
</html>