Switch to simple __IPYTHON__ global
#1059
Conversation
| # 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__' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Makes perfect sense, I just wanted to check (and have public record of the decision).
|
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. I've been checking for the existence of |
|
Yes, I guess part of the intent of this PR is for us to rationalize this... I'd say that |
|
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. |
|
Great, that's a good plan. We'll then merge this only with |
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.
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.
__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.
In 0.11 we added
__IPYTHON__activeas 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.