This pull request fails (merged 09b440a into 289fc01).

Just adding a test first

This pull request passes (merged dddd6d4 into 289fc01).

+1 to this approach. When a traceback is being rendered, execution is stopping anyway, so micro-optimizing to make the stack one frame shallower isn't really necessary.

Please check, however, that after this patch the traceback in various scenarios look OK. We have some fairly brittle logic in a few places that has hardcoded the 'distance' (measured in number of stack frames) between the user code and the traceback-handling code. So this extra frame may mess up that logic and need adjusting (I'm not sure it does, just asking that you check to be sure, as errors like that may not be detected in our test suite).

What isn't clear from this whole discussion is why we have two different functions render_traceback and _render_traceback_ which are ostensibly the same. Could we not just use one name or the other. I see in #2223 a claim that render_traceback is a "real public API" but I don't see that anywhere in the source for Python 2.7 or 3.2, nor really mentioned anywhere else in IPython.

render_traceback() is a public API in that we haven't marked it private in
any way, so third parties might use it (for example, in a graphical
debugger). But I don't want the hook to be on render_traceback() methods,
because other libraries or frameworks might have defined that on some
exceptions, but with a different API to what we expect.

Okay, I'll bite... the third party could just as easily have named it _render_traceback_ themselves too. Unless you want to call it _ipy_render_traceback_, I don't think you can guarantee a lack of collisions.

Anyway, my point is that render_traceback and _render_traceback_ appear to be exactly the same. Do you expect some exception class to have two different implementations of the two different methods? Certainly that would be confusing as the names are almost identical and it's not clear how they should behave differently.

They shouldn't be different.

render_traceback is a public method on the RemoteError class. In #2223, the notion of a generic API for custom traceback rendering in IPython was added, and under the name _render_traceback_, which is equivalent to the pre-existing method.

So the choice is:

1. remove render_traceback as a public method, and just use _render_traceback_ (not acceptable for a backport PR)
2. use render_traceback as the generic name
3. keep render_traceback, and add _render_traceback_ as the generic name.

There's not a huge difference between any of these.

As @bfroehle mentioned, one further option would be for the IPython-specific method to have a more IPython-specific name, e.g. _ipython_traceback_.

Okay, thanks for the history. I guess I'd advocate for 2 ("use render_traceback as the generic name") or some variation on ("keep render_traceback but use a more descriptive name like _ipython_traceback_").

1 is, as you point out, not acceptable for backport and the names in 3 are imho too similar.

Nevertheless, I'm okay with just merging the current pull request (i.e., 3) for the sake of expediency.

Shall I change _render_traceback_ to _ipython_traceback_, to give it more clarity of purpose?

Could do - my logic in using the more generic name was that other
interfaces (like IDEs) might want to use the same hook. There's no
particular reason for it to be specific to IPython. But render_traceback
with the underscores seems sufficiently unlikely to clash with anything
already in use purely by chance.

I'd be happy with just a docstring on the method to describe why it exists
and when it'll get called.

docstring added

This pull request passes (merged 417f9a9 into 289fc01).

Thanks. Looks ok to me now.

Looks fine to me too.