import foo vs. python -m foo

2008-10-28 Thread Simon Bierbaum

Hi all,

what is the difference between saying "import foo" in an interactive  
prompt and starting one using "python -m foo"? The -m switch is not  
covered in the man page, is it even officially supported? I'm asking  
because one of my modules fails on import in the second version but  
succeeds in the first.


Thanks, Simon

--
http://mail.python.org/mailman/listinfo/python-list


handling unexpected exceptions in pdb

2008-07-10 Thread Simon Bierbaum

Hi all,

I'm in an interactive session in pdb, debugging my code using  
pdb.runcall. Somewhere, an exception is raised and lands uncaught on  
stdout. Is there any way of picking up this exception and at least  
read the full message, or even accessing its stack trace to determine  
where exactly within the one line I just executed it was raised? This  
is where I'm stuck:


> /usr/local/apache2/bin/Model/Database.py(287)disconnect()
(Pdb) n
FlushError: FlushErr...perly.",)
> /usr/local/apache2/bin/Model/Database.py(287)disconnect()
(Pdb) import sys
(Pdb) sys.last_traceback
*** AttributeError: 'module' object has no attribute 'last_traceback'

Thanks, Simon

--
http://mail.python.org/mailman/listinfo/python-list


Re: handling unexpected exceptions in pdb

2008-07-10 Thread Simon Bierbaum


Am 10.07.2008 um 20:52 schrieb R. Bernstein:


Simon Bierbaum <[EMAIL PROTECTED]> writes:


Hi all,

I'm in an interactive session in pdb, debugging my code using
pdb.runcall. Somewhere, an exception is raised and lands uncaught on
stdout. Is there any way of picking up this exception and at least
read the full message, or even accessing its stack trace to determine
where exactly within the one line I just executed it was raised? This
is where I'm stuck:


/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) n
FlushError: FlushErr...perly.",)

/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) import sys
(Pdb) sys.last_traceback
*** AttributeError: 'module' object has no attribute 'last_traceback'

Thanks, Simon


I think basically you want runcall to be wrapped in a try block. So  
in pdb.py

instead of:

def runcall(*args, **kwds):
return Pdb().runcall(*args, **kwds)


Change with:

def runcall(*args, **kwds):
p=Pdb()
try:
  return p.runcall(*args, **kwds)
except:
  traceback.print_exc()
  print "Uncaught exception. Entering post mortem debugging"
  t = sys.exc_info()[2]
  p.interaction(t.tb_frame,t)
  print "Post mortem debugger finished."
  return None

Code like this appears near the bottom of the pdb.py file. If that
works, you may want to file a bug Python report to change pdb. Also
note that one may want to do the same thing on run() and runeval()

But also if this does what you want, please file a feature request  
to pydb:

  http://sourceforge.net/tracker/?func=add&group_id=61395&atid=497162

and I'll probably make it happen in the next release.

This is the first time I've heard of anyone using runcall.


My app is called from mod_python with the PythonEnablePdb option set  
to On, which makes mod_python call my handler function not directly,  
but wrapped into a pdb.runcall(). I figure I might not be the first  
one to use runcall under these circumstances ;-)


I'll definitely give your hack a try, thank you for your help!

Cheers, Simon
--
http://mail.python.org/mailman/listinfo/python-list