Ivan Carvalho

It would be nice but it would require a major redesign in the way we do iterators. Until [coroutines](https://doc.rust-lang.org/nightly/std/ops/trait.Coroutine.html) are stable we don't really have an equivalent for Python's `yield`...

Well I guess this is the other way around from #1033. Maybe they can be implemented together

I still need to remove ~~the ppc64 musl build that also failed the 0.14 release and~~ the test file... apart from that it should be fine

@mtreinish this should be ready to review, all the wheels build in https://github.com/IvanIsCoding/rustworkx/actions/runs/8400723506

> LGTM, and thanks for manually validating the builds. I just had 2 quick inline questions but not a blocker per say. > > The other question I had was...

@BastianZim @wshanks FYI I don’t know how this affects https://github.com/conda-forge/rustworkx-feedstock but for 0.15.x we will be distributing less binaries. I hope it simplifies your work in conda too

> I had noticed a similar failure in recent qiskit algorithms nightly builds - e.g here https://github.com/qiskit-community/qiskit-algorithms/actions/runs/7242612061/job/19728274840 One difference I had noticed is that when it ran ok it was...

> FWIW, this was a breaking api change made in Python 3.12.1's unittest module (which IMO was inappropriate for backporting in a stable point release, but there's no arguing with...

I think this is reasonable. We just need to be careful not to introduce Polars as a required dependency in Python. Having it as a dependency in Rust is fine...

Just a reminder to add `musllinux` images to the supported binaries. This was the `cibuildwheel` config that we used in 0.13.2 to launch it: ``` env: CIBW_BEFORE_ALL_LINUX: "apk add --no-cache...