Max Bachmann

It would be required to wrapp the `rapidfuzz` library first. Someone started to work on it a while ago (https://github.com/maxbachmann/rapidfuzz-cpp/issues/57), but never finished it. I do not have any experience...

> he PyPI tarballs for 0.23.0, since 0.24.0 is currently not uploaded to that system, seems to be empty so i'm basing my work on github tarballs I assume you...

You would need to package at least rapidfuzz for debian as well since it's used internally. I know someone wanted to do this in the past, but back then Cython...

ping @sandrotosi whats the state of this and is there anything I can help with? I have been contacted by others relying on the package in Debian about it being...

I think now that rapidfuzz and taskflow are packaged separately for debian this is no longer an issue.

> can you provide the benchmark code you are using, and details in the machine? this is not in line with what i’m seeing in my benchmarks and i’m wondering...

> This is just PyO3/Rust overhead, and the unicode normalization matters because going character by character isn't the right way to handle unicode strings since there are multi-length chars. Hm...

Hm I just had a look at the old implementation which calls: unicodedata_normalize as well. Maybe I should do this too. Sounds like this would be worth it in terms...

Hm especially for ascii strings (which I benchmarked) this should not have any performance impact, since they are already normalized. So it should be possible to avoid the overhead in...

> Current average difference from the C version is 1.5x in practice, I see that with a 200k long string you have different results, but I can't think of a...