Are you interested in how #Rust changes the ecosystem in #Python? Are you creating Python libraries using Rust code via #PyO3? Show your interest in participating in Rust #Summit in #EuroPython 2025 now! (details in the comment)

At last night’s @mug meeting we looked at a lot of different solutions to #adventofcode day 1 in many different languages. Two that were very interesting to me were #Zig and #haskell. The way these two languages worked was really quite fascinating. After seeing real code in these two languages, I can tell they are not for me; but they were interesting and illuminating nonetheless.

There was a solution entirely in #SQL. Another in #vim9script. Another in #swiftlang #swift (I don’t think that one’s in the repo yet). I wrote several implementations myself. The one I felt most proud of is #Python with the core written in #rustlang #rust tied together with #PyO3. The one I felt was maybe the best tool for the job was entirely based on #pandas. As I said in a previous post, I tried to solve it in #polars, but the API exposed by Polars at least as far as I could tell, made it no better than simple lists in Python. I need to get deeper knowledge here.

The repo lives here: https://github.com/MichiganUnixUserGroup/MUG-2025-03-11-Advent-of-Code.

Want to combine the power of Rust with the flexibility of Python? Kajetan Rachwał - ML Engineer from Robotec.ai will show you how! Join his talk, "Magic of Bindings: Introduction to Rust-Python bindings" to learn practical techniques for leveraging libraries like Polars and Orjson, using tools like PyO3 and Maturin and building high-performance applications through seamless integration.

For more information about our speaker and his talk, visit:
https://rustmeet.eu/en/magic-of-bindings-introduction-to-rust-python-bindings/

Been spending the week so far paying with #Rust and #Pyo3.

Rust is friggin amazing.

And so is Pyo3.

I've been working in python for the last 2-3 years, and learned that its a really... Let's be diplomatic and say it's not for me.

The idea of being able to just code modules in Rust and then let people use that in their python code sits well with me.

I did, during my previously mentioned workshop, do one thing to offend #Rust’s #borrowchecker. I was implementing an Account struct that had a current balance and a Vec containing a history of balances. This was using #PyO3 so there are some special types. Because of inheritance, I have self_ instead of self. Here’s the bad thing I said:

self_.history.push(self_.as_super().balance);

@algo_luca had to explain it to me. He didn’t even need to think about it. He instantly knew what was wrong. Now I am enlightened. I won’t make this particular kind of mistake again.

Of course the mistake is that I was trying to use a mutable reference (so I could push to history) and anything else at the same time.

Today I successfully wrote a #Rust implementation using #PyO3 that served as a package in my #Python program. Part of a presentation I’m doing for @mug. It’s day 1 of Advent of Code. I wrote four Python versions progressing from the simplest thing you would reasonably write up to packages and Rust. Here’s [the repo](https://github.com/MichiganUnixUserGroup/MUG-2025-03-11-Advent-of-Code). Lots of people in this repo demoing lots of languages. My stuff lives at `code\Python\wolf`

I’ve been writing a lot of #Python and #rust together over the last week or so, and I have things to say about that.

* even though I’ve been using Python for decades; when working in two languages at the same time I have to keep double-checking the syntax on _both_

* wow! Python can be a lot more succinct than Rust

I really like them both very much. Neither one is a replacement for the other. I’m a huge fan of types. The bigger your plans, the more important types are. They’re required in Rust, but I always use the in Python, too.

#PyO3 has proven to be incredible, though I still have so much to learn. What an amazing way to combine the two tools. Thanks. #mainmatter for leading me to this path.

I just attended a two-day workshop on #rust-#Python interoperability (the main glue between the two was #PyO3). Run by @mainmatter. The instructor was @algo_luca Two days, four hours each. Speeding up big Python programs with little bits of Rust. I enjoyed every second of it. Luca either knew the answer to your question off the top of his head or he was willing to dig right then to find it. The exercises were good as well as deep; the instruction was effective, smart, and respectful; the results were exciting. I learned a lot. I would happily attend another event of the same caliber.

Edit: originally I mistakenly said Mattermost. I meant to say Mainmatter. Thanks for pointing that out.

A cóż ja mogę teraz robić, w piątkowy wieczór?

Oczywiście, że wysyłam zgłoszenia do przypadkowych projektów #Python / #RustLang, prosząc o aktualizację wersji #PyO3 i nowe wydanie, po to, by móc wprowadzić wsparcie #PyPy 3.11 w #Gentoo. Bo, rzecz jasna, prawidłowy sposób rozwoju współczesnych paczek Pythona to przypadkowo przepisywanie ich fragmentów w Ruście, a potem ignorowanie konieczności aktualizowania zależności przez pół roku albo dłużej.

Tak, mówię o tych wszystkich paczkach, które w ogóle jeszcze nie wspierają PyO3 0.23.x.

A potem jeszcze przyjdą i powiedzą, że powinniśmy zostawić temat zależności i bezpieczeństwa autorom projektów.

What could I be doing right now, on a Friday evening?

Of course filing bugs on random #Python / #RustLang packages requesting a #PyO3 version update and a new release, to support #PyPy 3.11 in #Gentoo. Because obviously the right way to maintain modern Python packages is to rewrite random parts of them in Rust, then neglect updating their dependencies for half a year or more.

Yes, I'm talking about all the packages that don't even support PyO3 0.23.x yet.

And then they'll come and say that we should leave dependency management and security to upstreams.

Dobra wiadomość: jest łatka dla #PyO3 dla wsparcia #PyPy 3.11, więc ruszamy z aktualizacjami w #Gentoo do przodu.

Złe wiadomości:

1. Mówimy o #RustLang, więc każdą paczkę trzeba łatać z osobna.
2. Nie chcemy trzymać dziesiątek kopii tej samej łatki, więc chcemy ją ciągnąć z sieci. Niestety, nie możemy użyć oryginalnej kopii, bo modyfikuje pliki, których nie znajdziemy w archiwum crate.
3. No więc trzymamy własną kopię tej łatki, ograniczoną do dostępnych plików. Niestety, pasuje tylko do wersji 0.23.4, a że mnóstwo paczek Pythona używa 0.23.3, to mamy sporo aktualizowania. Ale przynajmniej w większości przypadków wystarczy podmienić cyferki na liście `CRATES`, i wykasować `Cargo.lock`.
4. …no chyba że dana paczka akurat wymusza dokładnie 0.23.3, albo używa 0.22.x bądź starszej wersji. Wtedy bez łatania `Cargo.toml` się nie obędzie.

No ale idziemy do przodu. Tyle że warto jeszcze wspomnieć, że z paczek Pythona robi się coraz większy bajzel cyklicznych zależności, ale to już inna bajka.

Good news is, there's an upstream patch for #PyO3 to support #PyPy 3.11, so the #Gentoo updates are progressing.

Bad news:

1. Since it's #RustLang, we need to patch every single package separately.
2. To avoid keeping a dozen copies of the same patch, we'd like to fetch it. Unfortunately, we can't use upstream pull request directly since it edits a bunch of files that aren't in the crate.
3. Ok, so we host a modified patch and we're good here. Unfortunately, the patch doesn't apply cleanly to the previous minor release (0.23.3), so we need to manually update PyO3 in a lot of #Python packages. Good news is, that's usually updating our `CRATES` list and removing `Cargo.lock`.
4. …except for these packages that pin exactly to 0.23.3, or are still on 0.22.x or earlier. Then we also need to patch `Cargo.toml`.

But yeah, things are going forward. And then of course Python packages are becoming an increasingly convoluted mess of cyclic dependencies, but that's another story.

Mi się wydaje, czy błędy testów w Maturinie są cosik straszne?

(tak, oczywiście, że #PyO3 blokuje teraz portowanie do #PyPy 3.11, i będziemy mieli z tym od jasnej cholery roboty, bo przecież każda zasrana paczka będzie wymagać starej wersji)

Is it just me or are #Maturin test failures just creepy?

(yes, of course #PyO3 is now a major blocker for #PyPy 3.11, and will require tons of work because of all the dependency pinning)

Speed up your Python with Rust! Join our hands-on online workshop to learn all about Rust-Python Interoperability with @algo_luca and @hdoordt . Dive deep into PyO3, Rust-powered Python extensions, concurrency, and more!

Details & registration https://ti.to/mainmatter/rust-python-feb-2025

uvとPyO3でPythonからRustを呼ぶ①（プロジェクト作成・Hello World実行まで）
https://qiita.com/nukipei/items/f096a1df6c8074b16150?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

My recent work on #CBOR diagnostic tools has culminated in the release v0.0.7 of the cbor-edn #RustLang crate, and the cbor-diag v1.1.0 #Python package (which is powered by the former, #maturin and #PyO3).
It is now easy to receive CBOR data structure with internal tags, and have them display like this:
{1: IP'2001:db8::1', 3: DT'2025-01-14T13:27:49Z'}
https://cbor-diag.readthedocs.io/en/latest/
https://docs.rs/cbor-edn/latest/cbor_edn/

#askmastodon #rust #rustlang

I've run into trouble passing data from Python into Rust via #pyo3. Does anyone have any ideas?

https://github.com/NREL/fastsim/commit/697a7b4ff3183dc3d4326fedce5d95b8ca4c5d63

Dzisiejsza zagadka z kategorii #RustLang / #Python w #Gentoo: dlaczego testy w pyproject-fmt sypią się z błędem konsolidatora na 32-bitowym #PowerPC? Albo raczej, po krótkim dochodzeniu: dlaczego nigdzie indziej się nie sypią, skoro najwyraźniej usiłują skompilować program testowy, używający crate #PyO3, nie linkując go z biblioteką libpython?

https://github.com/tox-dev/toml-fmt/issues/23

Today's #Gentoo #RustLang / #Python mystery: why do pyproject-fmt tests fail to link on 32-bit #PowerPC? Or, after a short investigation: why doesn't it fail on any other architecture when it's clearly trying to link a test program, using #PyO3 crate, but without actually linking to libpython?

https://github.com/tox-dev/toml-fmt/issues/23