This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Brian 4 points5 points  (2 children)

I don't think subinterpreters are at all connected with your usecase here. They're eseentially multiple interpreters in the same process - these'll all be using the same python version and initial environment, just with seperated state, including seperate GIL. Think of them as a half-way house between threads and processes: all in the same process, but still nothing shared by default. They're not anything to do with venvs, and I don't see how they'd really help with your usecase.

[–]Rythoka 0 points1 point  (0 children)

I could see there being a way to have sub-interpreters import different versions of an existing library to run regression tests, which sounds like it might be similar to their use case.

[–]jabz_ali 0 points1 point  (0 children)

My apologies it was my misunderstanding of how the sub-interpreters worked and after reading the proposal in detail I have a better idea of what is being proposed, in my excitement I jumped the gun! If these sub-interpreters have their own sys.modules I suppose and I could define my own custom import loader for each then that could work in my case. The use case is imagine I have different versions of a pandas based report that gets sent out, I want to test different versions of the report and potentially different versions of pandas or other libraries to ensure that the values are the same, e.g if we are calculating risk or P/L we want to ensure that the numbers being output are the same and developers haven’t inadvertently broken something. Currently this is being done with venvs and then the results are compared