HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
yglukhov
nimpy
Nim2018–2026
yglukhov / nimpy

nimpy

Nim - Python bridge

25Distinct people
34Mentions
0Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Nim - Python bridge

GitHub

Where it is used

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

What people are saying

No recommendation phrase was found in the indexed comments.

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

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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 year34 dated mentions

Observed mentions: 2018-09-22 12:19:57 UTC to 2026-10-13 15:50:41 UTC.

024682018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 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
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC615
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
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
nimpy Native language integration with Python has never been easier! Implementing a Python Module in Nim # mymodule.nim - file name should match the module name you're going to import from python import nimpy proc greet(name: string): string {.exportpy.} = return "Hello, " & name & "!" # Compile on Windows: nim c --app:lib --out:mymodule.pyd --threads:on --tlsEmulation:off --passL:-static mymodule # Compile on everything else: nim c --app:lib --out:mymodule.so --threads:on mymodule # test.py import mymodule assert mymodule.greet("world") == "Hello, world!" assert mymodule.greet(name="world") == "Hello, world!" Calling Python From Nim import nimpy let os = pyImport("os") echo "Current dir is: ", os.getcwd().to(string) # sum(range(1, 5)) let py = pyBuiltinsModule() let s = py.sum(py.range(0, 5)).to(int) assert s == 10 Note: here nimpy relies on your local python installation. Importing Nim Extensions Directly For a convenient way to import your Nim extension modules directly, you can use Nimporter. Misc The library is designed with ABI compatibility in mind. That is the compiled module doesn't depend on particular Python version, it should properly work with any. The C API symbols are loaded in runtime from whichever process has launched your module. Troubleshooting, Q&A Importing the compiled module from Python fails If you're getting ImportError: dynamic module does not define module export function ... make sure that the module you're importing from Python has exactly the same name as the nim file which the module is implemented in. Nimpy fails to find (proper) libpython The most reliable way to find libpython is find_libpython python package: pip3 install find_libpython python3 -c 'import find_libpython; print(find_libpython.find_libpython())' Then you can specify path to libpython using nimpy.py_lib.pyInitLibPath. Tracking issue: #171. Nim strings are converted to Python bytes instead of string nimpy converts Nim strings to Python strings usually, but since Nim strings are encoding agnostic and may contain invalid utf8 sequences, nimpy will fallback to Python bytes in such cases. Is there any numpy compatibility? nimpy allows manipulating numpy objects just how you would do it in Python, however it is not much more efficient. scinim offers API for performance critical numpy interop, and it is advised to consider it first. Nimpy also exposes lower level Buffer protocol, see raw_buffers.nim. tpyfromnim.nim contains a very basic test for this. Examples to use raw_buffers with numpy Does nim default garbage collector (GC) and ARC/ORC work? Yes. nimpy internally does everything needed to run the GC properly (keeps the stack bottom actual, and appropriate nim references alive), and doesn't introduce any special rules on top. So the GC question boils down to proper GC usage in nim shared libraries, you'd better lookup elsewhere. The following guidelines are by no means comprehensive, but should be enough for the quick start: If it's known there will be only one nimpy module in the process, you should be fine. If there is more than one nimpy module, it is recommended to move nim runtime out to a separate shared library. However it might not be needed if nim references are known to never travel between nim shared libraries. If you hit any GC problems with nimpy, whether you followed these guidelines or not, please report them to nimpy tracker :) Windows, threads and MinGW When compiling with --threads:on Nim will imply --tlsEmulation:on (Windows only) which prevents Nim runtime from initing properly when being called from a foreign thread (which is always the case in case of Python module). Adding --tlsEmulation:off when using MinGW toolchain (Nim's default on Windows) will introduce a dependency on libgcc_s_seh-*.dll, that newer python versions are often unable to find. One way to overcome this is to link with libgcc statically, by passing -static to linker, or --passL:-static to Nim. Exporting Nim types as Python classes Warning! This is experimental. An exported type should be a ref object and inherit PyNimObjectExperimental directly or indirectly. The type will only be exported if at least one exported "method" is defined. A proc will be exported as python type method only if it's first argument is of the corresponding type and is called self. If the first argument is not called self, the proc will exported as a global module function. If you define functions that looks like initTestType, destroyTestType, $, they can be exported as __init__ and __repr__ if the requirements are met. # mymodule.nim type TestType = ref object of PyNimObjectExperimental myField: string proc setMyField(self: TestType, value: string) {.exportpy.} = self.myField = value proc getMyField(self: TestType): string {.exportpy.} = self.myField # test.py import mymodule tt = mymodule.TestType() tt.setMyField("Hello") assert(tt.getMyField() == "Hello") Future directions High level buffer API Stargazers over time
Read the full README on GitHub

What Hacker News says

34 sources
Yeah. Other ecosystems are undeniably larger than Nim's. I keep hearing about how LLMs are going to nullify that advantage with "not so sloppy" ports of anything to any PLang, but I've yet to see that pattern materialize. "What is a clean interface" is probably a kind of subjective judgement call, but also very clearly depends on PLangs and even PLang cultures. For example, the microdependency culture of Rust/JS/Node have very little to do with the PLang's themselves. EDIT: With Cython how I mostly kept things organized was the "caller allocation" so common in C where memory was always managed the usual mostly refcounting way of CPython/NumPy, but I had dozens (maybe even 100) little "kernels" I could pass that memory into that could even use Intel/MSFT "intrinsic" asm calls (things like immintrin.h) or even just #include C code which
Read the rest
did similar. It didn't seem too bad to me, but Nim always seemed a more complete solution (at the PLang level - not counting ecosys). (And these days there is even NimPy (https://github.com/yglukhov/nimpy) to write low-level speed-up code for Python in Nim.)
In 11 year old unsoundness bugs found in Rust borrow checker
Good data. Thanks. I got a bit of a speed-up on python-3.12.5 - 0.599 down from 0.76863, but still slower than 2.7 on the same (old) i7-6700k CPU. { EDIT: All versions on both CPUs compiled on gcc-13 -O3, FWIW. } On a different CPU i7-1370P AlderLake P-core (via Linux taskset) I got a 1.5X time ratio (py3.12.5 being 0.371 and py2.7 0.245). Anyway, I should have qualified that it's likely the kind of thing that varies across CPUs. Maybe you are on AMD. And no, I sure don't have access to the CPUs I had back in 2007 anymore. :-) So, there is no danger of this being a very scientific perf shade toss. ;-) Same pypy3 also showed very minor speed-up for being inside a function. So, I think you are probably right about PyPy's optimization there and maybe it does just vary across PyPy versions. Not sure how @mg several levels up got his b
Read the rest
ig 2X boost, but down at the 10s of usec to 10s of ms scale, just fluctuations in OS scheduler or P-core/E-core kinds of things can create confusion which is part of the motivation for aforementioned https://github.com/c-blake/bu/blob/main/doc/tim.md. I should perhaps also have mentioned https://github.com/yglukhov/nimpy as a way to write extensions in Nim. Kind of like Cython/SWIG like stuff, but for Nim.
In Recent Performance Improvements in Function Calls in CPython
I mean honestly, the closest language to Mojo really is Nim. In the latest Lex Fridman interview with Chris Lattner [0] when he talks about his ideas behind Mojo it pretty much sounds like he's describing Nim. Ok fair, he wants Mojo to be a full superset of Python, but honestly with nimpy [1] our Python interop is about as seamless as it can really be (without being a superset, which Mojo clearly is not yet). Even the syntax of Mojo looks a damn lot like Nim imo. Anyway, I guess he has the ability to raise enough funds to hire enough people to write his own language within ~2 years so as not have to follow random peoples whim about where to take the language. So I guess I can't blame him. But as someone who's pretty invested in the Nim community it's quite a shame to see such a hyped language receive so much attention by people who should
Read the rest
In Mojo is now available on Mac
Ones that have not been mentioned so far: - npeg lets you write PEGs inline in almost normal notation: https://github.com/zevv/npeg - owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle - ratel is a framework for embedded programming: https://github.com/PMunch/ratel - futhark provides for much more automatic C interop: https://github.com/PMunch/futhark - nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy - questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable - nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm - chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos - cps allows arbitrary procedure rewriting in continuation passi
Read the rest
In Nim 2.0
Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy. Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python libraries. Actually come to think of it that might be the easiest way to write fast KiCad 6 plugins.. I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways. Problem is that Python would likely be too slow. Nimporter could be perfect. It looks really simple to setup.
In Erg: a statically typed language that is Python compatible
Maybe things have changed over the years. I've played around with Hy in 2017 and in the end felt like it combines the bad parts of Python with the bad parts of a Lisp. If you're forced to use Python it's usually because of one of 2 reasons: Either you need to work with colleagues on something (in which case almost certainly they wouldn't accept a lispified version of it) or because you need some of the libraries that are already implemented. In the latter case, you might say Hy is a good option. But why bind yourself to the slowness of Python when you could just as well use some fast Lisp (e.g. Common Lisp) that interacts with a Python interpreter similar to nimpy [0] from Nim? Not sure if such a thing already exists for CL, but it should be quite feasible to write and then you get access to all your Python library needs while actually us
Read the rest
ing a better language for the rest of your code. But I'm all ears on the real advantages Hy provides aside from being neat. [0]: https://github.com/yglukhov/nimpy
In Tutorial Series to learn Common Lisp quickly

Showing the 15 most recent of 34 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.