Multiple Interpreters

[PythonLinks]

Here is the PEP for multiple interpreters.
https://www.python.org/dev/peps/pep-0554/

It was rumored to be in Python3.7. Next I heard it would be in 3.8, then 3.9, now the Pep says provisional in 3.8, and they will make a decision about 3.9. I would not be surprised if multiple interpreters shipped first in gPython.

And I suspect that the cPython version will be one interpreter per OS thread. With gPython we could have thousands of interpreters.

I should also mention stackless.
https://github.com/stackless-dev/stackless/wiki

And finally the documents say that this is 1/5 th as fast as cPython. But I can easily get a server with 32 cores. And many applications now have little processing and lots of network I/O.

I just wonder what the killer app for this would be? It would be great to have a game, where a conference programming competition would be to win the multiplayer game, much like the snake competition at some recent Python conferences.

Warm Regards
Christopher Lozinski

[ncw]

My plan is to implement a "go" modules with some low level support for go facilities

• go routines
• channels
• mutex
• select (maybe)

This could then be used to make some higher level constructs eg the threading library.

My plan is to make a new interpreter for each goroutine so they can run together without locking. I'm not sure that is exactly the level at which the PEP you linked works but it might be!

Each goroutine would be able to access its own things without locking but accessing shared things would need locking.

I have a plan for how to implement the "go" module somewhere... It involves making some new "special functions" in the interpreter

gpython/vm/eval.go

Lines 1582 to 1591 in fff175c

	// As py.Call but takes an intepreter Frame object
	//
	// Used to implement some interpreter magic like locals(), globals() etc
	func callInternal(fn py.Object, args py.Tuple, kwargs py.StringDict, f *py.Frame) (py.Object, error) {
	if method, ok := fn.(*py.Method); ok {
	switch x := method.Internal(); x {
	case py.InternalMethodNone:
	case py.InternalMethodGlobals:
	return f.Globals, nil
	case py.InternalMethodLocals:

[corona10]

@ncw If we implement this feature based on goroutine, I think this feature can be unique to gpython. I like this issue.

[PythonLinks]

On Aug 11, 2019, at 12:37 PM, Nick Craig-Wood ***@***.***> wrote: My plan is to make a new interpreter for each goroutine so they can run together without locking.

Sounds great!

My plan is to implement a "go" modules with some low level support for go facilities go routines channels mutex select (maybe)

Mutex can wait for later. It is my belief that Erlang does not support Mutex. Select would be awesome, Erlang has it, but maybe that can also be later. Initially we Python developers could write some custom code to process the channel inputs. But we cannot write channels nor go routines.

I have a plan for how to implement the "go" module somewhere…

I would love to read your plan. I need to learn more about how Go implements Select. Implementing Select in Python would be a huge evolution of the language. Maybe those on this list who are Go Developers could give you some feedback before you started coding. I still want to know what is the killer app for multiple Interpreters. Warm Regards Chris

[drew-512]

suggest close issue -- addressed w/ #158

[sbinet]

fixed w/ #158.