Skip to content
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

Support for multiple interpreters? #1

Open
jacobwilliams opened this issue Jun 10, 2018 · 3 comments
Open

Support for multiple interpreters? #1

jacobwilliams opened this issue Jun 10, 2018 · 3 comments
Labels
enhancement New feature or request

Comments

@jacobwilliams
Copy link

It might be nice to add support for multiple interpreters (using Py_NewInterpreter(), Py_EndInterpreter(), etc.)

@ylikx ylikx added the enhancement New feature or request label Jun 10, 2018
@ylikx
Copy link
Owner

ylikx commented Jun 10, 2018

Thanks for the suggestion, it is certainly something to consider. Do you have an application, where sub-interpreter support would be useful right now?
In my opinion, threading support should be implemented before sub-interpreters. I think I'll look into threading in the nearer future, but before I can do that, there are some smaller enhancements I want to make (documentation, some ndarray methods, iterators).

@jacobwilliams
Copy link
Author

jacobwilliams commented Jun 10, 2018

Yes, my application is this: an interactive Fortran program that has the feature of allowing a user to write and load their own Python plugins to do specific things. Each plugin needs to be independent and not interfere with the others (since any number can be loaded at the same time). So, my thought was that the main program spawns off a new interpreter when a plugin is loaded and uses it for that plugin (and destroys it when the plugin is unloaded). The main program manages the loading/unloading/calling of each plugin, and they would all be completely independent of each other.

@ylikx
Copy link
Owner

ylikx commented Jun 10, 2018

As a proof of concept, you could try to call the necessary C API functions (Py_NewInterpreter(),...) directly.

One questions is, whether numpy plays nicely with subinterpreters. I don't know what the status is on that, but there seem to be problems:

numpy/numpy#665 which references
https://mail.scipy.org/pipermail/numpy-discussion/2009-July/044046.html
or
numpy/numpy#3961
https://docs.python.org/3.6/c-api/init.html#bugs-and-caveats

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants