Hacker News Reader

Comment by epanastasi | Hacker News Reader

As someone who works on both python and go day to day, I find this to be quite interesting.

Just tried this out on a reasonably complex project to see what it outputs. Looks like it only handles individual files and not any python imports in those files. So for now you have to manually convert each file in the project and put them into the correct location within the build/src/grumpy/lib directory to get your dependencies imported. Unless I missed something somewhere.. The documentation is a bit sparse.

Overall I think the project has a lot of potential and I'm hoping it continues to be actively developed to smooth out some of the rough edges.

View on HN

Thanks for trying it out! And sorry about the lacking documentation. I'll be fleshing it out over the next little while.

Your assessment is right: the grumpc compiler takes a single Python file and spits out a Go package. Incidentally, this means you can import a Python module into Go code pretty easily.

I don't have a ready solution for building a large existing project but I'll write up a quick doc to outline the process. The trickiest bit is that the Python statement "import foo.bar" translates to a Go import: import "prefix/foo/bar". Currently prefix always points at the grumpc/lib directory so that's one way to integrate your code, but I need to make it more configurable.

I hope this is a well thought out solution that can evolve into something great... and not just something built for a single purpose.

I question the transpiler. I think I'd much rather prefer a solution like Jython.

I'm confused because Jython runs on the JVM, but Go is a compiled language. Can you clarify?

Jython is a python interpreter written in Java. Grumpy is a python transpiler that converts python to navtive go object code.

Edited to add: The difference is that Jython doesn't covert python to JVM bytecode.

What's the advantage of writing an interpreter? Go already has an excellent runtime (scheduler, GC, etc)--why should this project reimplement it?

The interpreter could still use that stuff.

One advantage of an interpreter in general is that one important use case for Python is interactive scripting, as data scientists do.

Fair point. I would think it shouldn't require too much work to build a REPL on top of this. Rather than transpiling, you would parse the Python AST into the same runtime Objects that Grumpy constructs statically. Seems straightforward conceptually, though I'm sure it would be complex in practice.

I'm sure as this gets hacked on they'll be able to support consuming imports and doing all the conversion to go recursively

Reply on news.ycombinator.com