If we are in an IPython notebook, then IPython will have already been imported

Is this guaranteed in all versions?

Awesome idea! Thank you for the PR!

As @casperdcl says, need to double check whether IPython may have been renamed to jupyter in the latest releases. I have just tested with jupyter v7.13.0 (the latest stable version) and it works the same :-) This convention should not change in the foreseeable future since they are now working on v8. They used the same module name (IPython instead of jupyter) since years now, probably for retrocompatibility of old notebooks, I doubt they will change on a whim now.

As @casperdcl says, need to double check whether IPython may have been renamed to jupyter in the latest releases.

If that renaming occurred, then it would break the existing code too.

I asked on https://gitter.im/jupyter/jupyter and got this answer from @MSeal:

@lpsinger I dug into this topic a while back to figure out what the constraints / guarantees are as this comes up a lot in issues on github. This is the closest to detecting that you're in an ipython kernel accurately as you can do today: https://github.com/nteract/scrapbook/blob/master/scrapbook/utils.py#L46-L57. It's likely to continue working in IPython 8, but there's not a strong guarantee there.

hmm we go a little further and do 'IPKernelApp' not in get_ipython().config rather than just get_ipython().kernel is not None. Not sure which is better. Also note I think there isn't meant to be a way to distinguish between an ipy terminal and notebook, which makes things harder...

'IPKernelApp' not in get_ipython().config rather than just get_ipython().kernel is not None

Probably equivalent in forward compatibility.

Also note I think there isn't meant to be a way to distinguish between an ipy terminal and notebook

As I understand it, there's not meant to be a way to distinguish if you're in a ipykernel that's being controlled by a notebook or not. I don't believe there was an explicit emphasis on hiding if you're in ipython or ipykernel, but there certainly isn't any helper.

Any updates on this?

will likely be in tqdm>=4.47.0; thanks for following up

Is it possible to include this in v4.47.0 now that issue #993 has been created? I am having to use my branch for performance reasons in another project (http://git.ligo.org/emfollow/gwcelery).

Yes, it'll be in #993...

Codecov Report

Merging #955 into devel will increase coverage by 1.62%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##            devel     #955      +/-   ##
==========================================
+ Coverage   85.41%   87.04%   +1.62%     
==========================================
  Files          22       21       -1     
  Lines        1303     1250      -53     
  Branches      219      213       -6     
==========================================
- Hits         1113     1088      -25     
+ Misses        169      141      -28     
  Partials       21       21              

Thank you!