proptest VS PyO3

proptest: Property-based testing with random input generation.

Isn't proptest something that could handle this?

https://github.com/proptest-rs/proptest

Proptest is a Rust crate for property-based testing. Recently I wanted/needed to manually implement a proptest strategy for my own type, and I realized that there is not that much material on how to do it. So I wrote a post where I tried to describe what I learned. It's a bit niche, but I hope that someone at some point will find it useful.

Take a look at proptest.

Yes exactly, you can also add to this fuzzing and property based testing.

proptest is great! It generates random input data according to some rules, and if the input fails it saves random seed into a file so that failing inputs are guaranteed to be tested on the subsequent runs (as well as new random inputs). It also doesn't immediately stop on fail but tries to find a minimal failing input first.

The only other crate I could find is proptest, but it looks a lot more complicated, and I don't know if lets you skip the shrinking step as quickcheck does. I've been reading the book and going through the docs, but a quick answer would be appreciated.

We just released proptest 1.1.0, a property-testing framework for Rust. Proptest has recently found new maintainers, and this marks the first new release of proptest in ~2 years.

Hi, I'm working on a fuzzer, that fuzzes APIs based on OpenAPI specification. I'd like to implement shrinking. It means that when an interesting input (for the API) is found, I'd like to create the smallest possible input that still causes the same behaviour of the API. I'd like to implement a payload generation via proptest, because it already has the shrinking ability. I'm having issues implementing the JSON object as a proptest strategy. Here is what I tried so far. I explained it in a detail in stackoverflow question but it did not reach many people. Thanks for your help!

Third, if you're opting out of a compile-time safety guarantee in the name of performance, test heavily (high-coverage unit tests, property testing, fuzzing, differential fuzzing, etc.) and make use of tools like Loom and Miri's runtime data race detector for unsafe code, which can catch stuff that is beyond the scope of the compiler's guarantees.

Integrating Rust into Python, Edward Wright, 2021-04-12 Examples for making rustpython run actual python code Calling Rust from Python using PyO3 Writing Python inside your Rust code — Part 1, 2020-04-17 RustPython, RustPython Rust for Python developers: Using Rust to optimize your Python code PyO3 (Rust bindings for Python) Musing About Pythonic Design Patterns In Rust, Teddy Rendahl, 2023-07-14

This story unfolds as a captivating journey where the agile Flounder, representing the Python programming language, navigates the vast seas of coding under the wise guidance of Sebastian, symbolizing Rust. Central to their adventure are three powerful tridents: cargo, PyO3, and maturin.

I would not recommend FFI + ctypes. Maintaining the bindings is tedious and error-prone. Also, Rust FFI/unsafe can be tricky even for experienced Rust devs.

Instead PyO3 [1] lets you "write a native Python module in Rust", and it works great. A much better choice IMO.

[1] https://github.com/PyO3/pyo3

Same w/ Rust and Python, this is really neat because now each thread could have a GIL without doing exactly what you said. The pyO3 commit to allow subinterpreters was merged 21 days ago, so this might "just work" today: https://github.com/PyO3/pyo3/pull/3446

I expected someone to write a rust-based scripting language which tightly integrated with rust itself.

In reality, it seems like the python developers and toolchain are embracing rust enough to reduce the benefits to a new alternative.

https://github.com/PyO3/pyo3

Hey HN! I am one of the people working on Bytewax. Bytewax came out of our experience working with ML infrastructure at GitHub. We wanted to use Python because we could move fast, the team was very fluent in it, and the rest of our tooling was Python-native already. We didn't want to introduce JVM-based solutions into our stack because of the lack of experience and the friction we had trying to get Python-centric tooling working with existing solutions like Flink.

In our research, we found Timely Dataflow (https://timelydataflow.github.io/timely-dataflow/, https://news.ycombinator.com/item?id=24837031) and the Naiad project (https://www.microsoft.com/en-us/research/project/naiad/) as well as PyO3 (https://github.com/PyO3/pyo3) and we thought we found a match made in heaven :). Bytewax leverages both of these projects and builds on them to provide a clean API (at least we think so) and table stakes features like connectors, state recovery, and cloud-native scaling. It has been really cool to learn about the dataflow computation model, Rust, and how to wrangle the GIL with Rust and Python :P.

Would love to get your feedback :).

`pip install bytewax` to get started. We have a page of guides (https://www.bytewax.io/guides) with ready-to-run examples.

You can practice your Rust skills by writing performant and/or gluey extensions for higher-level language such as NodeJS (checkout napi-rs) and Python or complementing JS in the browser if you target Webassembly.

For instance, checkout Llama-node https://github.com/Atome-FE/llama-node for an involved Rust-based NodeJS extension. Python has PyO3, a Rust-Python extension toolset: https://github.com/PyO3/pyo3.

They can help you leverage your Rust for writing cool new stuff.