Switch to simple `__IPYTHON__` global #1059

Merged
merged 3 commits into from Dec 6, 2011

Conversation

Projects
None yet
2 participants
@fperez
Member

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.

+ # 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__'

This comment has been minimized.

@minrk

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?

@minrk

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?

This comment has been minimized.

@fperez

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.

@fperez

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.

This comment has been minimized.

@minrk

minrk Nov 29, 2011

Member

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

@minrk

minrk Nov 29, 2011

Member

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

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 29, 2011

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).

Member

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

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Nov 29, 2011

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Dec 6, 2011

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Dec 6, 2011

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.

Member

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 added a commit that referenced this pull request Dec 6, 2011

Merge pull request #1059 from fperez/__IPYTHON__
Switch to simple `__IPYTHON__` global to indicate an IPython Shell object has been created.  Note that this does *not* try to track whether user code is being executed by ipython via %run, nor whether the Shell object itself is running an interactive event loop or not.

So the answer for how people should query whether IPython objects are active is now simply

```
try:
  __IPYTHON__
except NameError:
  print 'not in IPython'
```

We do not attempt to track activity levels anymore, as we realized that logic was ultimately to brittle and error prone to be of any real use.

@fperez fperez merged commit 487b6b9 into ipython:master Dec 6, 2011

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Merge pull request #1059 from fperez/__IPYTHON__
Switch to simple `__IPYTHON__` global to indicate an IPython Shell object has been created.  Note that this does *not* try to track whether user code is being executed by ipython via %run, nor whether the Shell object itself is running an interactive event loop or not.

So the answer for how people should query whether IPython objects are active is now simply

```
try:
  __IPYTHON__
except NameError:
  print 'not in IPython'
```

We do not attempt to track activity levels anymore, as we realized that logic was ultimately to brittle and error prone to be of any real use.

jsoref added a commit to jsoref/pudb that referenced this pull request Aug 25, 2016

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:
ipython/ipython#1059

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