$\texttt{native-dot-py}$

Here’s something you can do but definitely shouldn’t.

To be clear, there is no trickery here. All these commands were executed as shown above¹.

The magic trick is actually in the codec header. In a move shamelessly stolen from dict-unpacking-at-home we introduce a .pth file that installs our decoder. The decoder lives in the package native-dot-py=0.1.0 and simply copies the file to a temporary directory, runs cargo build and loads the dynamic library as any other native extension would.

Don’t try this at home

There is no reason to. None at all.

Why I wrote this

I was chatting to some folks, raving about how easy pyo3 makes writing rust plugins to python, when one commented that it seemed mostly like a boilerplate issue and if c had a better preprocessor it should be about as easy. He also suggested python as a processor which is when I had the idea of JIT compiling native modules. I’m sure someone else has done this too.

Its bad, but not terrible

I mean, my codec does cache builds so future imports are super speedy and can even handle specifying dependencies. I have some standards.

It solves a problem

The main thing is that this proves that you can do crazy things. There are plenty of places to hook into the python import system and this is possibly the most egregious. But it works.

Also, whenever I feel like sprinkling a little rust into my python projects, I always have to fight off instructions that tell you to use maturin and make sure you package it carefully and so on. Sometimes I just want a quick and dirty single file!

Don’t use this at home

But seriously this is a terrible idea. I’m certainly never going to use this.

Even though it solves a problem I have.

And works.

I’m sure I’ll never use it…