The code module claims to emulate Python's interactive interpreter but it fails to emulate displaying of the exception cause.

It can utilize traceback._iter_chain to do this (see traceback.print_exception)

PyPy's fixed this here:

https://bitbucket.org/pypy/pypy/commits/1341a432e134

The tests just need to be adapted to the stdlib test suite

Here's an updated patch for the stdlib, with adapted tests.

Could anyone review this patch, please?

I am on the fence as to whether this should be treated as a bug fix or enhancement. Claudiu's pydev post gives this as the current InteractiveInterpreter behavior.

------------------------------

>>> try:
...    1 / 0
... except ZeroDivisionError as exc:
...    raise IOError from exc
...
Traceback (most recent call last):
  File "<console>", line 4, in <module>
OSError

This certainly is not an exact emulation (given below), but is it severe enough to be a bug, and moreover, would fixing it break code?
Again from Claudiu's post: with the patch.

---------------------------------

>>> try:
...    1 / 0
... except ZeroDivisionError as exc:
...    raise IOError from exc
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
OSError

I verified that this is exactly what 3.4.0 prints for interactive input, But... the Idle Shell also prints the above, plus it adds (or received from the user process) the offending code lines just as when the code is read from a file.
...
File "<pyshell#0>", line 2, in <module>
1 / 0
ZeroDivisionError: division by zero
...
File "<pyshell#0>", line 4, in <module>
raise IOError from exc
OSError

Is there a reason the console interpreter cannot do the same? (Changing this would be a different issue, but one this would depend on.)

Python's interactive interpreter doesn't show the offending code lines too. And given the fact that code.InteractiveInterpreter tries to be an emulation of the default interpreter, first the change should be addressed directly there, I think. But I agree that it could be useful.

I would lean toward bug fix. I'm sure this was just overlooked when exception chaining was added, and as Claudiu says, the contract of code is to emulate the interactive interpreter, so not doing so in this instance looks like a bug to me.

It is certainly conceivable that it could disrupt working programs, but I would think most such would be interactive programs that would benefit from the fix without breaking. Does anyone know of a counter example or can think of a use case for the code module that this change would be likely to break?

(Note: if there is a use case that somehow parses the output, introducing blank lines and extra traceback clauses could easily be a breaking change...but is there such a use case?)

Well, for instance, my use cases with InteractiveInterpreter are for debugging or creating custom interpreters for various apps and in those cases the patch helps, by giving better debugging clues through the exception cause. I agree that this was overlooked when exception chaining was added. Also, idlelib's PyShell is based on InteractiveInterpreter, but in addition, it implements the exception chaining.

Also, solving this issue seems to be, partially, a prerequisite for bpo-14805.

If the patch doesn't need anything else, can it be committed?

Claudiu, did you see Jim Jewett's review on Rietveld?

Actually, no, it seems that I didn't receive any mail regarding them. I'll update the patch accordingly.

Here's the new version which fixes the comments from the review.

New changeset 2b212a8186e0 by R David Murray in branch 'default':
bpo-17442: Add chained traceback support to InteractiveInterpreter.
https://hg.python.org/cpython/rev/2b212a8186e0

After reconsidering Terry's idle example, it seems to me that the change could adversely impact existing code that already works around the lack of chained tracebacks, even as idle does. So I committed this to 3.5 only as an enhancement.

Thanks Claudiu.

As an aside, isn't it a (pre-existing) bug that if an excepthook exists, it gets passed None for the traceback?

Indeed, it's a preexisting bug. I'll try to come up with a patch shortly.