Python bindings `xapian.cvar` raises strange NameError in unexpected circumstances

[Jean-Paul Calderone]

This behavior:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xapian
>>> issubclass(xapian.cvar, object)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: Unknown C global variable
>>> 

is rather undesirable. This likely stems from the behavior of getting the __class__ attribute of xapian.cvar. It's quite unexpected for issubclass to raise a NameError and automated discovery tools which inspect any object they can find in search of things (for example, a test discovery tool) don't expect it. TypeError is something that's more commonly raised by issubclass. Perhaps that would be a better behavior here. Or still better, if it could just return False (or true, if it's actually possible to get the right type object to pass as the second argument), that would be ideal.

[Richard Boulton]

I'm guessing you came across this issue due to some automated discovery tool failing? Normally, there would be no reason to access xapian.cvar.

I think this is really a SWIG issue (though that doesn't mean we shouldn't try and fix it) - the xapian python bindings don't define cvar; it's something added by SWIG when making the bindings. I'm not sure exactly what its purpose is - something to do with global C variables, for the message! Xapian doesn't use any global variables, though, and certainly doesn't expose any such things through the bindings; we could possibly work around this problem by adding a "del cvar" to the end of the xapian.py file (which we can do easily without having to work out what SWIG is up to). A better fix would be to fix SWIG so that cvar returns a more reasonable exception when accessed.

I note that "help xapian.cvar" also raises NameError - this is also unhelpful.

[Olly Betts]

Bumping milestone to 1.1.1 as there's no patch yet and this doesn't require an incompatible change.

[Olly Betts]

Triaging milestone:1.1.1 bugs.

[Olly Betts]

It seems BAD_VALUENO comes from xapian.cvar from adding printf tracing to where we scan, but nothing else seems to and we can probably persuade that to be provided as other constants are.

And it's trying to read bases when it fails. If I add code to return Py_NONE for that, then I get:

TypeError: issubclass() arg 1 must be a class

Is that better? I really don't know this stuff well enough to know, but if it is we can probably make that change in SWIG.

But perhaps it would be better to persuade BAD_VALUENO not to be in cvar, and then (if it doesn't already) get SWIG to just suppress cvar if it would be empty.

[Olly Betts]

That should be __bases__...

[Olly Betts]

SWIG seems to handle these (at file scope) as variables you can't write to:

const int CONST1 = 1;
static const int CONST2 = 2;

But these (at file scope) are handled as "constants" (Python apparently doesn't have native constants, but these cases are handled differently in the SWIG-generated code to how the above cases are):

#define CONST3 3
enum { CONST4 = 4 };
%constant int CONST5 = 5;

The SWIG developers seem to agree that the first two should handled the same as the last three, so I think we just need to wait for a fix, or fix it there ourselves. I had a quick poke at a workaround using #ifdef SWIG in xapian/types.h, but the things I tried didn't work (the best I could achieve was making BAD_VALUENO a constant with value -1).

I don't see this as key to fix in 1.1.x since changing how BAD_VALUENO gets set up shouldn't affect code using the Python bindings, so bumping to 1.2.x.

[Olly Betts]

Adding these lines to the interface file causes xapian.BAD_VALUENO to be handled as a constant, and cvar is no longer generated:

%ignore Xapian::BAD_VALUENO;                                                
%constant Xapian::valueno BAD_VALUENO = Xapian::BAD_VALUENO;

Fixed in trunk r14694. Marking for backport to 1.0.21 as the patch is low risk.

[Olly Betts]

Backported in r14710.