-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In-process kernel support (take 3) #2724
Conversation
…eton. Since the in-process group makes its own shells, it should avoid creating the global singleton.
One of the methods in the inprocess kernel objects used a local variable called `raw_input` that was mistakenly converted to `input` during the 2to3 conversion.
As I mentioned before, this PR covers a frequent use case for me and I think it would be great to have it in IPython. Based on comments on the previous PR by @fperez , it also sounds like it would be useful for IPython in general. I have some time to spend on it at the moment if there is any other issue to be fixed... BTW, I tried merging the PR to master and all tests stil pass. |
Thanks for tackling this. It might be a few days before anyone looks at it in detail, but we're definitely interested in supporting this case. |
Who would be plausible reviewers for this PR? |
@takluyver, I have reviewed the Python 3 compatibility fixes. The fixes look good (thanks, @pberkes!). At the time of my departure, these were the only outstanding issues of which I was aware. I hope that this PR can now move forward. |
Thanks, @epatters. |
I think this looks pretty solid now. My only thought is that I would put these new base classes in IPython.kernel instead of IPython.inprocess. |
# Utility classes | ||
#----------------------------------------------------------------------------- | ||
|
||
class BlockingChannelMixin(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure it makes sense for these base classes to in in IPython.inprocess
, I view the main kernel code to be more fundamental.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable and @minrk evidently shares this view. Are BlockingChannelMixin
and SocketABC
the only classes that need to be moved?
Overall, this look like really clean code. I just left a few inline comments. |
In-process kernel support (take 3)
This is great, but is there any documentation or example code to actually implement this? The old gist that epatters wrote does not work. I am guessing there were some name changes somewhere in here? |
I am also excited about this feature, but can't seem to find any documentation about how to use it except for one thing! I did see the attached |
@tomcraw00 @nehalecky I update the example by @epatters |
I would like to double-check: This work has not been backported to the 0.13.x branch, and is currently only available on master, right? |
Correct |
|
That's correct, some things have been renamed. There is an example in IPython now. |
Great, I missed that. Thanks! |
Could someone please help with my SO question : Hmm, I am wondering if this code even made it into 13.2 Many thanks. |
Ok, so I modified the code fragment from SO (see above). but I am getting the same error. I am on OS X and using QT (4.8.4) and PyQt4 (4.10.1) The git version of ipython is whatever is current today, |
There is an example in the IPython tree. Your error indicates that you have imported PyQt prior to importing any IPython objects, and the IPython qt code requires PyQt API v2, which is not the default for PyQt in Python 2. |
Many thanks, that solved it. I would suggest that the error message mentions the potential import sequence issue. |
that's a good idea, thanks |
In-process kernel support (take 3)
This PR continues PR #2397 now that @epatters is offline. The previous PR has been closed and this one will take its place.
I fixed the Python3 issues that got PR #2397 stuck.