Having to "print" before method invocation?

Jeremy L. Moles jeremy at emperorlinux.com
Wed Mar 8 10:17:08 EST 2006


Hey Fredrik, thanks for responding. :) Your posts are always helpful and
informative!

On Wed, 2006-03-08 at 15:41 +0100, Fredrik Lundh wrote:
> Jeremy L. Moles wrote:
> 
> >I have an object (written as part C extension, part pure Python) called
> > foo that I've been using without much fuss for a few months now.
> > However, in my latest project (a rather large one involving
> > multi-threading, pygtk, etc.), I'm seeing some really strange behavior
> > with a particular instance of my foo object.
> >
> > About midway through my program, any attempt to use the instance fails;
> > however, if I add print statements before trying to invoke methods on
> > it, the foo object instance works fine.
> 
> fails in what way?

Unfortunately, very silently. There aren't any exceptions thrown or
anything. The be more specific, the C part of the object is a wrapper
around some socket Send/Recv functions (that interface w/
wpa_supplicant). The problem I'm getting is that unless I add that print
statement, wpaobject.Recv() returns "", whereas with the print statement
it returns what it should (a large string representing the response from
wpa_supplicant).

More strange is that this is the first time I've had to do this. Up
until this point, every unittest and app has succeeded without such
trickery.

> if you get a spurious exception, it's very likely that your C extension sets the
> exception state (either directly or because some API function it uses fails), but
> forgets to report this back to Python.
> 
> e.g. if you have a C function that does something like
> 
>     PyErr_SetString(PyExc_AttributeError, "blah blah"):
> 
>     Py_INCREF(Py_None);
>     return Py_None;
> 
> instead of
> 
>     PyErr_SetString(PyExc_AttributeError, "blah blah"):
> 
>     return NULL;
> 
> the interpreter won't raise the exception immediately (since it expected you to
> return NULL if something went wrong), but the exception may still be raised at
> a later time, if you run interpreter code that does something like
> 
>     do something
>     if (PyErr_Occurred())
>         ... /* this will catch your error even if "something" succeeds */ ...
> 
> *or* it may be masked, by code that does
> 
>     PyErr_Clear();
>     do something
> 
> the actual exception might give you additional clues (e.g. if you get a KeyError,
> look for unchecked dictionary accesses in your code, etc).
> 
> hope this helps!
> 
> </F> 
> 
> 





More information about the Python-list mailing list