Switch to simple `__IPYTHON__` global #1059

Merged
merged 3 commits into from Dec 6, 2011

2 participants

@fperez
IPython member

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
IPython/core/interactiveshell.py
@@ -573,6 +573,20 @@ class InteractiveShell(SingletonConfigurable, Magic):
self.magic_logstart()
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
IPython member
minrk added a note Nov 28, 2011

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
IPython member
fperez added a note Nov 29, 2011

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
IPython member
minrk added a note Nov 29, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@minrk
IPython member

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
IPython member

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
IPython member

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
IPython member

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment