HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
google
grumpy
Go2017–2026
google / grumpy · Archived

grumpy

Grumpy is a Python to Go source code transcompiler and runtime.

29Distinct people
36Mentions
1Explicit recommenders
10.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Grumpy is a Python to Go source code transcompiler and runtime.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

From looking in the code, this is my favorite part so far: https://github.com/google/grumpy/blob/75a35b4b30afb049b9cfff... making python threads as lightweight as goroutines…

teabee89 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year36 dated mentions

Observed mentions: 2017-01-04 17:39:07 UTC to 2026-04-05 09:44:23 UTC.

051015202017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 20 mentions; 1 submissions, 19 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC20119
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC817
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC110
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Grumpy: Go running Python Overview Grumpy is a Python to Go source code transcompiler and runtime that is intended to be a near drop-in replacement for CPython 2.7. The key difference is that it compiles Python source code to Go source code which is then compiled to native code, rather than to bytecode. This means that Grumpy has no VM. The compiled Go source code is a series of calls to the Grumpy runtime, a Go library serving a similar purpose to the Python C API (although the API is incompatible with CPython's). Limitations Things that will probably never be supported by Grumpy exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically-compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain, which would be unwieldy and impractically slow. C extension modules: Grumpy has a different API and object layout than CPython and so supporting C extensions would be difficult. In principle it's possible to support them via an API bridge layer like the one that JyNI provides for Jython, but it would be hard to maintain and would add significant overhead when calling into and out of extension modules. Things that Grumpy will support but doesn't yet There are three basic categories of incomplete functionality: Language features: Most language features are implemented with the notable exception of old-style classes. There are also a handful of operators that aren't yet supported. Builtin functions and types: There are a number of missing functions and types in __builtins__ that have not yet been implemented. There are also a lot of methods on builtin types that are missing. Standard library: The Python standard library is very large and much of it is pure Python, so as the language features and builtins get filled out, many modules will just work. But there are also a number of libraries in CPython that are C extension modules which will need to be rewritten. C locale support: Go doesn't support locales in the same way that C does. As such, some functionality that is locale-dependent may not currently work the same as in CPython. Running Grumpy Programs Method 1: make run: The simplest way to execute a Grumpy program is to use make run, which wraps a shell script called grumprun that takes Python code on stdin and builds and runs the code under Grumpy. All of the commands below are assumed to be run from the root directory of the Grumpy source code distribution: echo "print 'hello, world'" | make run Method 2: grumpc and grumprun: For more complicated programs, you'll want to compile your Python source code to Go using grumpc (the Grumpy compiler) and then build the Go code using go build. Since Grumpy programs are statically linked, all the modules in a program must be findable by the Grumpy toolchain on the GOPATH. Grumpy looks for Go packages corresponding to Python modules in the __python__ subdirectory of the GOPATH. By convention, this subdirectory is also used for staging Python source code, making it similar to the PYTHONPATH. The first step is to set up the shell so that the Grumpy toolchain and libraries can be found. From the root directory of the Grumpy source distribution run: make export PATH=$PWD/build/bin:$PATH export GOPATH=$PWD/build export PYTHONPATH=$PWD/build/lib/python2.7/site-packages You will know things are working if you see the expected output from this command: echo 'import sys; print sys.version' | grumprun Next, we will write our simple Python module into the __python__ directory: echo 'def hello(): print "hello, world"' > $GOPATH/src/__python__/hello.py To build a Go package from our Python script, run the following: mkdir -p $GOPATH/src/__python__/hello grumpc -modname=hello $GOPATH/src/__python__/hello.py > \ $GOPATH/src/__python__/hello/module.go You should now be able to build a Go program that imports the package "__python__/hello". We can also import this module into Python programs that are built using grumprun: echo 'from hello import hello; hello()' | grumprun grumprun is doing a few things under the hood here: Compiles the given Python code to a dummy Go package, the same way we produced __python__/hello/module.go above Produces a main Go package that imports the Go package from step 1. and executes it as our __main__ Python package Executes go run on the main package generated in step 2. Developing Grumpy There are three main components and depending on what kind of feature you're writing, you may need to change one or more of these. grumpc Grumpy converts Python programs into Go programs and grumpc is the tool responsible for parsing Python code and generating Go code from it. grumpc is written in Python and uses the pythonparser module to accomplish parsing. The grumpc script itself lives at tools/grumpc. It is supported by a number of Python modules in the compiler subdir. Grumpy Runtime The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs. These data structures and operations are defined in the grumpy Go library (source is in the runtime subdir of the source distribution). This runtime is analogous to the Python C API and many of the structures and operations defined by grumpy have counterparts in CPython. Grumpy Standard Library Much of the Python standard library is written in Python and thus "just works" in Grumpy. These parts of the standard library are copied from CPython 2.7 (possibly with light modifications). For licensing reasons, these files are kept in the third_party subdir. The parts of the standard library that cannot be written in pure Python, e.g. file and directory operations, are kept in the lib subdir. In CPython these kinds of modules are written as C extensions. In Grumpy they are written in Python but they use native Go extensions to access facilities not otherwise available in Python. Source Code
Read the full README on GitHub

What Hacker News says

20 sources
It's at least partially a factor of the cython implementation, because pypy does a pretty great job doing JIT compilation, and making python fast. That's without the resources of Google behind it, too. (Though I've seen some python compiler "20%" style projects roll around: https://github.com/google/grumpy). That said, python does have a lot of magic functionality that makes predicting paths through the program difficult for a compiler
In Why Python is Slow: Looking Under the Hood (2014)
Interesting. The goal is "small and handy environment that mainly focusing on creating API servers or microservices". Having moved from Ruby to Go in the last year or two I'd be really interested in what language features they're pushing with that goal. I really enjoyed my work with Ruby, but I have found Golang pretty quick at these "backend" type work. On the back of this, I dug around a bit around for other transpilers to/from Golang. So far: - http://havelang.org/ - https://github.com/jcla1/gisp - https://github.com/google/grumpy (Python to Go) - https://tardisgo.github.io/ (Go to Hexe) - https://github.com/gopherjs/gopherjs (Go to JavaScript) If there are any others, be keen to find out.
In Goby: A new Ruby-inspired language written in Go
This comes up over and over again in the Python community. If you will allow me to paint with broad strokes, as I'm going to lump a lot of things together for the sake of ease of understanding, I am not speaking for every python user(s) out there. There seems to be a huge tug of war between companies/corporate users and the PSF & more independent users. The smaller (if you will, these are going to be big in the python community) 'shops' and library developers, and users all are or have migrated to Python 3 ages ago. Django now is going to be python 3 only in the foreseeable future (I know they EOL'd their python2 compatible libraries). The Software foundation itself wants it to be essentially toast by 2020. Things like Pyramid, Flask, Bottle, and even numpy & scipy have started moving in a direction of having python3 be their 'first' upda
Read the rest
te (I think in the case of Flask and Bottle, they're end of life support for python2 is happening as well, though they haven't announced anything official, they seem to be adding new features and promising features that will only make sense in python3). Yet, big 'corporate' users like Google (Look at you, grumpy https://github.com/google/grumpy) and Apple (still shipping with 2.7...and why!) and large universities all seem to be stuck on python 2. Because of this, this to me really hurts the community and its holding back full development of python3 and python generally going forward. Why are companies holding back the state of a language (and then complaining about it) instead of diverting their ya know, massive resources, to get their own libraries and technologies up to current stack? Why do so many people want to stay on python2. I'll never understand. For what its worth, the latest version of python3 (3.6, well, 3.6.1, but the release notes for this is for 3.6) haves a ton of forward thinking built in concurrency improvements and technologies that these companies could easily take advantage of! https://docs.python.org/3/library/concurrency.html https://docs.python.org/3/library/asyncio.html https://docs.python.org/3/library/multiprocessing.html
In Parallel Python
mk44·Mar 12, 2017Submission

Google will kill Python 3, and it might be a good thing

We know that there are issues with the Python echosystem at large [1]. Google is heavily invested in Python 2, and thus created Grumpy [2], which is a new Python 2 runtime, in Golang. A company like Google, stepping in, will inevitable lead to the sorting out of many of the issues [1], and introduce new developments for Python 2. The Golang backend of Python will enable the development of many benefits we see in Golang (built in concurrency?, speed?, easy package management?) This would mean that the community will gravitate towards python 2. What do you think? [1] * Fragmentation of package managers: Pip, Conda, etc.. * Fragmentation of runtime: Pypy, CPython, Jython, Cython, etc.. * Golang (and probably Grumpy in the future) doesn't suffer from these issues, because a central entity (Google) is leading it. [2] https://github.com/google/
Read the rest
grumpy
25 points · Open discussion
My reading of the "Developing Grumpy" section of the README [0] is that Grumpy is primarily a transpiler, and that's what `grumpc` is. It says right there it takes your Python, compiles it to Go, and then you run `go build` to build a Go executable. The "runtime" comes in at this point. It sounds like `grumpc` compiles Python objects down to stubbed-out Go objects, which depend on the functionality implemented in grumpy for the implementation of those stubs. "The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs." To me, this mostly sounds like a Python->Go transpiler with special hooks to more easily facilitate Pythonic access in Go. If anything, it seems to support my original point that transpilers are custom-built even more; from my high-level and probably wrong
Read the rest
reading, it looks like instead of a full-scale Python-to-Go transpiler, Grumpy's developer realized it would just be easier to implement if he made the programs dependent on his "runtime", which he could freely do because he was running his own project on it and he can execute that project through `grumpy` just as easily as he could through anything else. Such options would probably not be available to someone who was tasked with writing a generic Python-to-Go transpiler that was expected to work anywhere that Go works. I also could be misreading this, because again, I've never used it, and maybe by "runtime" the author really does just mean "library", and it all compiles down to a standard Go application. That'd be cool. [0] https://github.com/google/grumpy/tree/aa58aa68717f6ac2ebf40f...
In Nylas Mail is now free
It's different from using a C++ compiler to build a Qt application because it's in the opposite direction. Qt is a toolkit that lays on top of C++, which your compiler translates to machine code. Qt is still C++. Everything is the same language and gets compiled directly into the code that the machine knows how to execute. With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level. I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be diffi
Read the rest
cult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote. If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs). My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go. [0] https://github.com/google/grumpy
In Nylas Mail is now free
IIUC, it's not about accessing python libs from go. It's for accessing go libs from your python program and transpiling that python code to go source and compile it with go tool chains. Eg: python code (from blog post) from __go__.net.http import ListenAndServe, RedirectHandler handler = RedirectHandler('http://github.com/google/grumpy', 303) ListenAndServe('127.0.0.1:8080', handler)
In Grumpy: Go running Python

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.