Failure in new dreload tests under Python 3.2

[fperez]

In #1457, @bfroehle introduced a revamped dreload with proper tests, but apparently those don't work correctly under python 3.2. See the console log for the details, the exception itself is:

======================================================================
ERROR: Test that dreload does deep reloads and skips excluded modules.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/case.py", line 134, in run
    self.runTest(result)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/case.py", line 152, in runTest
    test(result)
  File "/sp/lib/python/cpython-3.2/lib/python3.2/unittest/case.py", line 477, in __call__
    return self.run(*args, **kwds)
  File "/sp/lib/python/cpython-3.2/lib/python3.2/unittest/case.py", line 435, in run
    result.addError(self, exc_info)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/proxy.py", line 134, in addError
    plugins.addError(self.test, err)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/plugins/manager.py", line 94, in __call__
    return self.call(*arg, **kw)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/plugins/manager.py", line 162, in simple
    result = meth(*arg, **kw)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/ipython-0.13.dev-py3.2.egg/IPython/testing/iptest.py", line 96, in addError
    return self.orig_addError(test, err, capt)
  File "/home/slave/jenkins/shiningpanda/jobs/d99552f2/virtualenvs/ff035a1d/lib/python3.2/site-packages/nose/plugins/xunit.py", line 201, in addError
    tb = ''.join(traceback.format_exception(*err))
  File "/sp/lib/python/cpython-3.2/lib/python3.2/traceback.py", line 180, in format_exception
    for value, tb in values:
  File "/sp/lib/python/cpython-3.2/lib/python3.2/traceback.py", line 122, in _iter_chain
    cause = exc.__cause__
AttributeError: 'str' object has no attribute '__cause__'

I don't really understand this one, b/c the error that is being printed comes from core python code, not the new code in the PR, so I'm puzzled. But obviously since this comes from new code, we should try to fix it sooner rather than later to get our buildbots back in the green. @takluyver, any ideas from your py3 knowledge here?

[minrk]

@fperez have you seen PR #1625?

[fperez]

Argh, never mind, I just saw that. This is a dupe, closing now. I was just flushing my inbox in order and hadn't gotten to that yet...

[takluyver]

This is from issue #1626, ccing ipython-dev.

On 18 April 2012 20:58, Fernando Perez wrote:

[snip]
 File "/sp/lib/python/cpython-3.2/lib/python3.2/traceback.py", line 180, in format_exception
   for value, tb in values:
 File "/sp/lib/python/cpython-3.2/lib/python3.2/traceback.py", line 122, in _iter_chain
   cause = exc.cause
AttributeError: 'str' object has no attribute 'cause'

I don't really understand this one, b/c the error that is being printed comes from core python code, not the new code in the PR, so I'm puzzled.  But obviously since this comes from new code, we should try to fix it sooner rather than later to get our buildbots back in the green.  @takluyver, any ideas from your py3 knowledge here?

That was masking another error, hopefully fixed in #PR 1625, but the
message itself likely indicates a bug in nose/xunit.

I've seen the message ('str' object has no attribute 'cause')
before. traceback.format_exception() now expects the second argument
to be an exception instance, but some exceptions raised by built-in
code can seemingly still result in sys.exc_info()[1] being a string,
which is a throwback to Python's old exception model. This should
possibly be fixed in Python itself, but I don't currently have a
minimal failing example.

Thomas

[fperez]

On Wed, Apr 18, 2012 at 1:18 PM, Thomas Kluyver
reply@reply.github.com
wrote:

I've seen the message ('str' object has no attribute 'cause')
before. traceback.format_exception() now expects the second argument
to be an exception instance, but some exceptions raised by built-in
code can seemingly still result in sys.exc_info()[1] being a string,
which is a throwback to Python's old exception model. This should
possibly be fixed in Python itself, but I don't currently have a
minimal failing example.

Thanks for the writeup; it does indeed look like a core Python bug,
somewhere it's emitting string exceptions which supposedly don't exist
anymore.

Cheers,

f