Importing friendly into IPython appears to break %pprint functionality

[kevinbowen777]

Hello,
I am running into an issue when working within IPython and need to toggle
the pprint functionality either 'off' or 'on'.

Here is the error message I receive when trying to run the "%pprint" magic
command from within IPython:

  Code block [2], line 1, in <module>                                           
    get_ipython().run_line_magic('pprint', '')                                  
  File "LOCAL:/IPython/core/interactiveshell.py", line 2351, in run_line_magic  
    result = fn(*args, **kwargs)                                                
  File "LOCAL:/decorator.py", line 232, in fun                                  
    return caller(func, *(extras + args), **kw)                                 
  File "LOCAL:/IPython/core/magic.py", line 187, in <lambda>                    
    call = lambda f, *a, **k: f(*a, **k)                                        
  File "LOCAL:/IPython/core/magics/basic.py", line 308, in pprint               
    ptformatter.pprint = bool(1 - ptformatter.pprint)                           
AttributeError: 'BaseFormatter' object has no attribute 'pprint'

---

IPython config information for importing friendly:

## lines of code to run at IPython startup.
  c.InteractiveShellApp.exec_lines = [
      "from friendly.ipython import *",
    ]

Should I be placing a set_formatter() call here? I tried set_formatter('rich') or 'jupyter' with no success.

I have also tried commenting the above out of my ipython_config, starting
IPython, and then manually importing with the same results. Additionally,
I tried to limit my import of friendly from a * import to only using:
from friendly.ipython import what, where, why
again with the same error message.

---

Here is my system information:

Python 3.9.7 (default, Aug 31 2021, 13:28:12) 
IPython 7.28.0 -- An enhanced Interactive Python. Type '?' for help.
friendly_traceback 0.4.54; friendly 0.4.18.

I have confirmed that this also happens with IPython 7.20 & Python 3.8.10.
My distros are Mint 20.2 & Manjaro 21.1.5

Please let me know if you need any additional information, from me. Or, let
me know if I am doing something wrong, myself, to cause this problem.

Thanks for your work on this module. I appreciate it.

[aroberge]

I've never used pprint with IPython. I will need to investigate.

[aroberge]

I believe that I have found the cause of the error and could create a workaround. With Friendly, I use https://github.com/willmcgugan/rich to do some formatting (including adding colours) and when I install Rich, it seems to override some ipython defaults. (I don't know how yet).

As a work around, I could create a new version of friendly that would never use Rich. This would preclude having coloured tracebacks from friendly, but it would still work.

This is what it would look like:

I'd need to change the way it is invoked; likely something like:

from friendly.ipython_plain import *

If this would be useful to you, I could have this done within an hour (easily!).

[kevinbowen777]

Thanks for the quick reply!
I am in no hurry; but, I am around for a few hours to test some things for you, if you need. Having improved messages is better than nothing at all(though, I do like the rich text formatting). ;-)

As far as using %pprint in IPython, take something like this, for example:
[name for name in dir(__builtins__) if name > 'a']
pprint, when on, will add a '\n' after each item in a list. I don't really use it for much more than saving screen space for long lists.

[aroberge]

I've uploaded a new version to PyPI: friendly version 0.4.19.

To use it so that you can use IPython's %pprint, import the following:

from friendly.ipython_plain import *

This will not use Rich (and no colours).

I'm going to ask a question on Rich's forum, referring to this issue. Perhaps there might be a way to disable the pprint done by Rich, to achieve something similar to turning off IPython's own pprint.

[aroberge]

See Textualize/rich#1603, and feel free to add any useful information!

[kevinbowen777]

Toggling %pprint now seems to work as expected. Detailed error messages from friendly also appear to be working for me. Thanks for the really quick response and (partial) resolution!

Hopefully, a solution for restoring color to the messages via rich is possible. Feel free to ping me if you want me to look into anything further. I'll check back later tonight, or tomorrow.
Thanks again for being amazingly responsive! Hope the rest of your weekend is quieter.

[aroberge]

Keeping this issue open until I can figure out if it is possible to use Rich and toggle pprint (or equivalent).

[kevinbowen777]

Would it be worthwhile, for me, to test anything for you with the new version? Happy to help out. Haven't seen any response from the rich project on your bug report.

[aroberge]

I have not changed anything since I uploaded to PyPI the last version (which you already tried, I believe). I've tried to dig in the code for Rich to see if I could fint a way to fix this, but without success so far. I might give it another try later this week.

[kevinbowen777]

OK. Thanks. I may poke around at rich. Not a terribly high priority for myself either.

[kevinbowen777]

See willmcgugan/rich#1603, and feel free to add any useful information!

For some reason, this bug doesn't appear as an open issue on the rich repo.

[aroberge]

I put this in the "Discussion" area of the project, as it did not seem to be suitable to call it a bug as such.

[kevinbowen777]

OK. In my opinion, is should be a bug, But, thanks for engaging them.

I think, if they are indeed, overwriting pprint, that is unexpected behavior.

We'll see what they say, if anything.

[aroberge]

Filed as an explicit issue: Textualize/rich#1611

[aroberge]

I've uploaded a new version of friendly.ipython which no longer raises a traceback when invoking %pprint. This new version (0.4.20) should be available from PyPI momentarily.

In [2]: %pprint
%pprint is not supported by Rich (used by friendly).
If you absolutely need to use %pprint, import friendly.ipython_plain
instead of friendly.ipython.

[kevinbowen777]

Hmm. I'm not sure that 4.20 is working as expected.

I am using import friendly.ipython_plain and am unable to toggle pprint on/off and continue to get this message. I am getting the friendly error messages(obviously not in color).

[aroberge]

@kevinbowen777 My apologies: I messed up by putting the redefinition of pprint in the wrong file.

I'm attempting to correct this now. I will need to do another correction later, to prevent changing the formatter via set_formatter in friendly.ipython_plain as it could re-enable Rich by accident.

[aroberge]

New version uploaded.

If %pprint support is not added in Rich over the next couple of weeks, I will see if I can find a way to disable Rich in IPython once it has been enabled. (I think I know how to do it, in principle, but it would be messy.) If I can do this, then I should be able to implement support for an equivalent to %pprint in friendly.python, without having to resort to importing a different module.

[kevinbowen777]

Just installed 4.21, and it is working as expected with both import friendly.ipython and import friendly.ipython_plain

[aroberge]

@kevinbowen777 New version (0.4.22) which no longer require the use of friendly.ipython_plain (which has been deleted). It was not as messy to do as I feared.

Entering %pprint disables Rich (if enabled) and switches to a plain format in addition to toggling off the IPython pretty printing. Use either dark() or light() (based on the background colour of your terminal) to enable Rich (and resetting %pprint to being ON).

[kevinbowen777]

What I am seeing when re-enabling %pprint, is that I need to quit and then re-start ipython before the syntax highlighting is restored.

I am using an xfce4-terminal with a black background.

[aroberge]

Weird: I don't need to restart ipython. This is what I see with a Windows Terminal with black background.

Using the %pprint magic command

Re-enabling the colour support for dark background, which reenable (rich) pretty printing.

If you simply toggle pretty printing using %pprint, it does not restore the colour output.

[kevinbowen777]

Ah. I see what you are saying. I had missed your point re: using dark() and light(). Thanks for spelling it out for me. ;-)

[aroberge]

@kevinbowen777 I'm going to leave this issue open until I add some relevant information in the documentation. Feel free to comment further, especially if you find some bugs! ;-)

[aroberge]

With the newest version of Rich, %pprint works as expected with IPython. There is no need to reenable Rich (by calling dark() or light()) after toggling %pprint back on. Since that is the case, there is no need to document anything.

After uploading a new version of friendly (0.4.25) to Pypi, this issue can now be closed.

[kevinbowen777]

I've upgraded both friendly and rich, now when I start IPython, I am getting the following:

Traceback (most recent call last):                                              
  Code block [1], line 1, in <module>                                           
    from friendly.ipython import *                                              
AttributeError: '_State' object has no attribute 'exception_before_import'

I can confirm that I do not need to re-rerun either dark() or light() after running %pprint again. Let me know if you need additional info from me. Thanks.

[aroberge]

On Mon, Nov 8, 2021 at 12:05 AM Kevin Bowen ***@***.***> wrote: I've upgraded both friendly and rich, now when I start IPython, I am getting the following: Traceback (most recent call last): Code block [1], line 1, in <module> from friendly.ipython import * AttributeError: '_State' object has no attribute 'exception_before_import' I can confirm that I do not need to re-rerun either dark() or light() after running %pprint again. Let me know if you need additional info from me. Thanks.

When you start friendly, do you get the following: friendly-traceback: 0.4.59 friendly: 0.4.25 The attribute 'exception_before_import' is a recent addition to friendly-traceback (which should have been updated when you updated friendly).

…

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZXQWHTBN2YNPRPJPJLTDUK5EAZANCNFSM5GD7QBWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[kevinbowen777]

Hrm. No, I was getting friendly_traceback 0.4.55; friendly 0.4.25.

I ran another pip install --upgrade specifically for friendly-traceback and that resolved the issue.

IIRC, upgrading friendly also pulled in the upgrade for friendly-traceback; but, that doesn't seem to be the case, for me, this time.
I tried using another venv and upgraded friendly, and I confirmed that I needed to upgrade friendly-traceback separately.

[aroberge]

Weird ... it did work for me in a new environment, even though the specific requirement was not updated everywhere. I've updated setup.cfg and uploaded a new version for friendly (0.4.26) which should work properly.

[kevinbowen777]

Just tried it out in a new venv and it works cleanly now, for me. An upgrade of friendly now pulls in the new friendly-traceback version. Let me know if you want me to check anything else out. Thanks for your work. Cheers!