Switch to simple `__IPYTHON__` global #1059

merged 3 commits into from Dec 6, 2011


None yet

2 participants

fperez commented Nov 28, 2011

In 0.11 we added __IPYTHON__active as a global, managed with the builtin trap, to try and detect nested ipythons. But in reality that mechanism is very fragile, the values aren't always right, and I think it's just unnecessary complexity. People do ask often, however, for some way of knowing whether they're running in ipython or not.

So this pr proposes that we simply create a global flag in __builtin__, called __IPYTHON__ (like the name we used to have and that it turns out people were already relying on). This flag will just be set to True at shell creation, with no attempt to delete it, or otherwise manage 'activity' (in event driven contexts this is a futile battle). I think this is the simplest thing we can do that will reasonable cover most cases without making promises we can't keep.

I'd like this merged before 0.12 so we're back to an api similar to what we had for most of our life from now on. I have the feeling that 0.12 will be when many people start really porting their codes forward, so minimizing api breakage here is worthwhile.

@minrk minrk commented on the diff Nov 28, 2011
@@ -573,6 +573,20 @@ class InteractiveShell(SingletonConfigurable, Magic):
def init_builtins(self):
+ # A single, static flag that we set to True. Its presence indicates
+ # that an IPython shell has been created, and we make no attempts at
+ # removing on exit or representing the existence of more than one
+ # IPython at a time.
+ builtin_mod.__dict__['__IPYTHON__'] = True
+ # In 0.11 we introduced '__IPYTHON__active' as an integer we'd try to
+ # manage on enter/exit, but with all our shells it's virtually
+ # impossible to get all the cases right. We're leaving the name in for
+ # those who adapted their codes to check for this flag, but will
+ # eventually remove it after a few more releases.
+ builtin_mod.__dict__['__IPYTHON__active'] = \
+ 'Deprecated, check for __IPYTHON__'
minrk Nov 28, 2011 Member

I don't know if anyone was actually doing this, but if anyone was using this as the counter that it is, this will still break it. Do we want to worry about that?

fperez Nov 29, 2011 Member

Yes, I realize that. But I really doubt anyone was, given that even we were inconsistent in using it (the value isn't the same in kernels than it is in the terminal b/c our update logic was in the wrong place). So I think this is just an example of an api that didn't really work out, and which we might as well kill quickly rather than let it live further and possibly get entrenched when it shouldn't.

minrk Nov 29, 2011 Member

Makes perfect sense, I just wanted to check (and have public record of the decision).

minrk commented Nov 29, 2011

This seems quite sensible, and seems ready for merge.

What are the official ways to:

a) determine that you are in an IPython interactive namespace (e.g. %run -i)
b) determine that you are in a process with IPython instance somewhere.

I've been checking for the existence of get_ipython for b), but I don't know about a). If I read correctly, __IPYTHON__ is also for b).

fperez commented Nov 29, 2011

Yes, I guess part of the intent of this PR is for us to rationalize this... I'd say that __IPYTHON__ is for b), and I guess we don't really have anything special for a), because get_ipython gets injected into enough places that even a plain %run (without -i) will see it. Perhaps we should add another flag, say __IPYTHON__interactive for this, that would only be written to the user_ns when we prepare it? Kind of a mouthful, but if that sound like a good idea we can mull on the name.

minrk commented Dec 6, 2011

Since we have never had an answer for a), maybe we shouldn't be unnecessarily intrusive in the user_ns. If someone asks for it, then we can.

fperez commented Dec 6, 2011

Great, that's a good plan. We'll then merge this only with __IPYTHON__, which should be sufficient and does simplify things out. Thanks for the review.

@fperez fperez merged commit 487b6b9 into ipython:master Dec 6, 2011
@jsoref jsoref added a commit to jsoref/pudb that referenced this pull request Aug 25, 2016
@jsoref jsoref Avoid trying to use IPython unless it seems like it is present
__IPYTHON__ was apparently removed from only 0.11,
and then the developers got negative feedback and restored it
for 0.12:

Various versions of IPython break demand loaders badly.
The current version is 5.1 or thereabouts, I am using 4.x.

It is unlikely that someone would be using 0.11 (July 2011),
so look for this variable first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment