Unwanted phabsend on that one (decidedly prematurate, sorry).

I believe to have addressed your immediate concerns.

As I've tried to make clear in the changeset description, this is still work in progress.

What I would probably do is still implement the Rust part with multiple structs but then wrap it in an enum for the python API.

@kevincox, thanks for the review, updated version available.

@kevincox Thanks for the reviews !

@pulkit, thanks, abandoned this one.

Oops sorry, this one has already been queued by @pulkit (sent it by email, but it was still a draft in my stack).

We had half an hour of direct chat about this yesterday, with @martinvonz and @marmoute. Here's a summary

Hi Martin,

I thought of "closure" as well, but I fear it has too many possible meanings, "transitive closure" being one of them in that context (certainly related, but not the same thing), and of course the closures in functional programming.

@yuja I'm trying to find a compromise between our points of view : I'd like very much it to be run automatically (hence an integration test), and you want to be parametrizable. So, I'm pushing a version that has these two properties, working with env variables, since command-line arguments are already used by the testing framework. Hope it'll suit you, if it doesn't, I'll put it in examples and find a way to run it anyway

@yuja we don't need a seed to reproduce: failed examples contain all the information (that's a difference with the Python version)

@yuja now that 4.9 is out, I'm getting back to this.

@yuja the doc you're linking is about integration tests, so it wouldn't apply to these tests which are really unitary in my mind. Usually the main difference would be the access to the private constructs that the integration tests can't perform, but it's true that most of these implementations are public anyway.