-
-
Notifications
You must be signed in to change notification settings - Fork 373
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
Proposal: remove some ipyparallel-specific functionality #17
Comments
No objections from me. |
Missed the boat for 4.0 on this one, but I still think it's the right move in the long run. |
FYI, we use the ipyparallel bits in wrapper kernels (via metakernel) to run other languages in parallel. This is quite powerful, and hope that we can keep that functionality. |
@dsblank how do you use those kernels in parallel? Are you using ipyparallel at all? I mainly mean to remove the native-serialization stuff (data-pub, apply), not anything else, which shouldn't affect any kernels other than IPython. |
@dsblank I've implemented most of what I intended in ipython/ipyparallel#61. I don't understand enough about how your use of parallel in metakernel works, so I don't know how to tell what would be affected. Can you provide some examples that I can test with? |
Sorry for the delay. Here is a short example:
Hopefully that will still work. Thanks! |
@dsblank thanks, that still works after the above PR. Since it looks like you are sitting on top of the existing IPython engines and clients, moving the implementation shouldn't have any effect on your use case. |
Thanks for checking @minrk ! It is quite nice to have Parallel Java, Parallel Scheme, Parallel Cobol ... |
bump to 6.0 ? |
Mainly the
apply
message-related bits. These aren't part of the wider Jupyter message protocol, and are wholly Python specific. These can be moved to ipyparallel, and attached to the Kernel in a subclass.The text was updated successfully, but these errors were encountered: