imported method from module evaluates to None in some cases

A

Andrew

Hi:

I'm having a problem in some zope (2.10) code (HTTPResponse.py) where
a method that gets imported somehow evaluates to None in certain cases
which causes a TypeError exception to be raised (eg: TypeError:
'NoneType' object is not callable). The code excerpt is below where
the exception is raised on the line with the comment 'TypeError IS
RAISED HERE'. I've read that the thread stack size may be insufficient
but the I compiled a test pthreads program on the same system to get
the default. I used pthread_attr_getstacksize() and it returned
3657952 (3.5 mb?). I would imagine that's enough. Any ideas how this
could occur?

from PubCore.ZEvent import Wakeup

def close(self):
DebugLogger.log('A', id(self._request),
'%s %s' % (self._request.reply_code, self._bytes))
if not self._channel.closed:
self._channel.push(LoggingProducer(self._request,
self._bytes), 0)
self._channel.push(CallbackProducer(self._channel.done),
0)
self._channel.push(CallbackProducer(
lambda t=('E', id(self._request)): apply
(DebugLogger.log, t)), 0)
if self._shutdown:
self._channel.push(ShutdownProducer(), 0)
Wakeup()
else:
if self._close: self._channel.push(None, 0)
Wakeup() # TypeError IS RAISED HERE
else:
# channel closed too soon

self._request.log(self._bytes)
DebugLogger.log('E', id(self._request))

if self._shutdown:
Wakeup(lambda: asyncore.close_all())
else:
Wakeup()

self._channel=None #need to break cycles?
self._request=None
 
H

Hrvoje Niksic

Andrew said:
I'm having a problem in some zope (2.10) code (HTTPResponse.py) where
a method that gets imported somehow evaluates to None in certain cases
which causes a TypeError exception to be raised (eg: TypeError:
'NoneType' object is not callable). The code excerpt is below where
the exception is raised on the line with the comment 'TypeError IS
RAISED HERE'.

Could the "certain cases" involve automatic invocation of the close
method at interpreter shutdown? While the interpreter shuts down,
module-level variables are set to None. This is documented in some
detail in http://www.python.org/doc/essays/cleanup/, steps C1-C3.
 
A

Andrew

Could the "certain cases" involve automatic invocation of the close
method at interpreter shutdown? While the interpreter shuts down,
module-level variables are set to None. This is documented in some
detail inhttp://www.python.org/doc/essays/cleanup/, steps C1-C3.

That's possible. I didn't know that. Now I guess the question for me
is why and where did the interpreter shutdown? I don't see log entries
relating to it. Is it possible for me to intercept an interpreter
shutdown so I can find out the location and possibly the reason why
the interpreter abruptly shuts down?
 
H

Hrvoje Niksic

Andrew said:
That's possible. I didn't know that. Now I guess the question for me
is why and where did the interpreter shutdown? I don't see log entries
relating to it. Is it possible for me to intercept an interpreter
shutdown so I can find out the location and possibly the reason why
the interpreter abruptly shuts down?

Normally the interpreter exits due to a call to sys.exit or simply
because the main module finishes, and this is what I had in mind.
When that happens, module contents get cleared, and __del__ finalizer
methods can get invoked with the module in a half-cleaned-up state.

I don't know why the interpreter would shut down abruptly, but I
suppose you could inspect the traceback to see what exactly caused the
exception?
 
P

Paul McGuire

I don't know why the interpreter would shut down abruptly, but I
suppose you could inspect the traceback to see what exactly caused the
exception?- Hide quoted text -
While you puzzle out the root cause, could something like this help
alleviate your race condition at interpreter shutdown?

-- Paul


def safe_call(fn, alt):
if fn is not None:
return fn
return alt

def WakeupAlt():
print "Wakeup has been set to None"

def Wakeup():
print "This is your wakeup call..."

safe_call(Wakeup,WakeupAlt)()
Wakeup = None
safe_call(Wakeup,WakeupAlt)()

prints:
This is your wakeup call...
Wakeup has been set to None
 
P

Peter Otten

Paul said:
While you puzzle out the root cause, could something like this help
alleviate your race condition at interpreter shutdown?

-- Paul


def safe_call(fn, alt):
if fn is not None:
return fn
return alt

def WakeupAlt():
print "Wakeup has been set to None"

def Wakeup():
print "This is your wakeup call..."

safe_call(Wakeup,WakeupAlt)()
Wakeup = None
safe_call(Wakeup,WakeupAlt)()

prints:
This is your wakeup call...
Wakeup has been set to None

Hm, what makes you confident that neither WakupAlt() nor safe_call() may be
set to None, too?

Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top