Skip to content
This repository has been archived by the owner on Aug 13, 2021. It is now read-only.

Add support for IPython #126

Closed
aroberge opened this issue Nov 30, 2020 · 9 comments
Closed

Add support for IPython #126

aroberge opened this issue Nov 30, 2020 · 9 comments
Labels
Discussion: future work Used to discuss items for future consideration. enhancement New feature or request

Comments

@aroberge
Copy link
Owner

After the backlog issue is taken care of, I should look at seeing how to integrate with IPython.

@aroberge aroberge added Discussion: future work Used to discuss items for future consideration. enhancement New feature or request labels Nov 30, 2020
@Carreau
Copy link

Carreau commented Nov 30, 2020

Great ! Thanks; if you ever get to it I would be ok to have friendly TB be automatically enabled in IPython if installed.

@aroberge
Copy link
Owner Author

aroberge commented Dec 9, 2020

@Carreau I just released a new version (0.2.0) of Friendly-traceback with experimental support for IPython. It's not ideal, but it is a first step. I took three screenshots to illustrate the project status.

First, an example using Friendly-traceback's own console, running on Windows with the new Windows terminal and using Rich (https://github.com/willmcgugan/rich)

image

Above, I used where() to show additional information after the traceback; other commands are available. I just added a subset of what is found on https://aroberge.github.io/friendly-traceback-docs/docs/html/repl.html

Next, showing how to enable Friendly-traceback within IPython, running the exact same example as above, but without any syntax colouring.

image

Finally, using Rich to provide colours, I display the same result as before.

image

The result is clearly not satisfying. I'm using my own styles instead of Rich's default which might be why this happens.

So, it is ready for experimentation, but more work is needed before it could be considered for serious work.

= = =
Unrelated: I see IPython is using a rather "unfriendly" scheme for caching results of computation in an attempt at doing preventing duplicates. I was wondering if something much simpler could not be used instead. I would suggest to use a global counter ("kernel count") which would be a simple integer that could be incremented by 1 each time a new CachingCompiler instance is intantiated. This would allow unique names of the form
<ipython-input-cell-kernel>. Of course, I might be missing something obvious which might prevent this from working ...

@aroberge
Copy link
Owner Author

aroberge commented Dec 9, 2020

I just noticed that SyntaxErrors are not captured. So, there is definitely more work to be done - in addition to getting the syntax colouring to work properly.

@aroberge
Copy link
Owner Author

aroberge commented Dec 9, 2020

SyntaxError support added.
image

@alexmojaki
Copy link

Take note of the overlap:

  1. IPython uses stack_data by default in master
  2. friendly-traceback may use stack_data (Introduce first dependencies?  #96)
  3. @willmcgugan has said he plans on using some of the libraries, including perhaps stack_data. I suggested it in Suggestion: use stack_data for better tracebacks Textualize/rich#145 which is now closed but based on the last comment and https://www.reddit.com/r/Python/comments/jxsiyn/even_more_prettierer_tracebacks/gcyqr27/?context=3 it seems to still be in the cards.

@aroberge
Copy link
Owner Author

aroberge commented Dec 9, 2020

I know that IPython uses stack_data.

I spent a few hours trying to use it as a replacement for the formatter I wrote, as I like how it works with "pieces" instead of lines. However, I could not get it to work reliably both in the console and when running an external file; it was also giving some problems when dealing with SyntaxErrors.

One problem I have is that I remove from the stack frames that belong to friendly_traceback modules and some Python modules. I also do this now for embedding with IPython; other users (such as hackinscience) do that as well.

@Carreau
Copy link

Carreau commented Dec 9, 2020

Unrelated: I see IPython is using a rather "unfriendly" scheme for caching results of computation in an attempt at doing preventing duplicates. I was wondering if something much simpler could not be used instead. I would suggest to use a global counter ("kernel count") which would be a simple integer that could be incremented by 1 each time a new CachingCompiler instance is intantiated. This would allow unique names of the form
<ipython-input-cell-kernel>. Of course, I might be missing something obvious which might prevent this from working ...

This logic may predate me joining the project, so I would have to dig into it to figure this out;
The traceback features of IPython are among the oldest ones (from before bool were introduced in Python), so I'm fine trying new things.

I'd also love to have a way to render traceback to HTML without having to go through the ansi escape code.

@aroberge
Copy link
Owner Author

Experimental support for JupyterLab; using Pygments to write html, and using from IPython.display import display, HTML to show the tracebacks.
image

@aroberge
Copy link
Owner Author

After doing some relatively minor changes, I've added a section to the documentation about using Friendly-traceback with IPython, either in console environments or in notebook environments. The documentation can be found here: https://aroberge.github.io/friendly-traceback-docs/docs/html/ipython.html

Closing this issue as I consider the original goal accomplished.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Discussion: future work Used to discuss items for future consideration. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants