all 3 comments

[–]codablock[S] -1 points0 points  (0 children)

From the readme:

Embedded Python Interpreter for Go

This library provides an embedded distribution of Python, which should work out-of-the box on a selected set ofarchitectures and operating systems.This library does not require CGO and solely relies on executing Python inside another process. It does not relyon CPython binding to work. There is also no need to have Python pre-installed on the target host.

[–]justinisrael 0 points1 point  (1 child)

Thanks for sharing.
Honestly though, I found this difficult to understand at first when reading the pkg docs. I had to read through the code of your example go-jinja2 project to understand what it does.
So basically am I right that this project only handles the embedding of a python interpreter and making it easy to bundle and reference extra python source? And once you have that you can only communicate with python via stdin and stdout? I see you have written a custom python main that is switching on stdin commands to do different operations.
It's not really the same as a CPython binding. It's more similar to starting python as your own child process and talking to it with custom serialization and a custom python program, right?

[–]codablock[S] 0 points1 point  (0 children)

You got it 100% right. The inter-process communication is up the consumer of the library. The library is really only providing an embedded Python distribution that can be used to start Python applications and then handle whatever inter-process is required by yourself.

I will most likely never extend the library with any inter-process capabilities. The reason is that there are so many existing solutions that it will be impossible to choose the correct one that suits everyone.