Here is the PEP for multiple interpreters. <a href="https://www.python.org/dev/pep

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

suggest close issue -- addressed w/ <a class="issue-link js-issue-link" data-error-tex

fixed w/ <a class="issue-link js-issue-link" data-error-text="Failed to load title" da

Multiple Interpreters about gpython HOT 5 CLOSED

go-python commented on June 12, 2024 1

Multiple Interpreters

from gpython.

Comments (5)

ncw commented on June 12, 2024

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:

from gpython.

corona10 commented on June 12, 2024

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

from gpython.

PythonLinks commented on June 12, 2024

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

from gpython.

drew-512 commented on June 12, 2024

suggest close issue -- addressed w/ #158

from gpython.

sbinet commented on June 12, 2024

fixed w/ #158.

from gpython.

Recommend Projects

Multiple Interpreters about gpython HOT 5 CLOSED

Comments (5)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	// 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: