Skip to content
Snippets Groups Projects
  • Georges Racinet's avatar
    be765f6797cc
    rust-pyo3: initial port of PySharedRef · be765f6797cc
    Georges Racinet authored
    At this point, we have a full translation, with some tests.
    The tests are high level, demonstrating the case of iterating over
    `HashSet` as a doctest. The assertions are written as Python statements,
    in order not to be obscure and to resist later refactorings.
    The rust-cpython integration tests will be ported in a subsequent changeset.
    
    We find the example of iterating over `HashSet` to be more convincing than
    the iterating over `Vec`, the example provided in rust-cpython, because
    in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and
    an index. This would of course be reimplementing the iterator, but is simple
    enough that it leads the reader to believe that having a reference is the
    problem, whereas the problem is having a reference that is itself enclosed
    in a type with lifetime that can be arbitrary complex. It took us some
    time to remember that subtlety, and hence we reworded the documentation
    to stress that point.
    
    We decided to put this work a separate crate, which makes running `cargo test`
    work for the crate, but not for the entire workspace: the `extension-module`
    feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as
    default and run the tests with `--no-default-feature` in Makefile, hence in CI.
    
    An important difference with rust-cpython is that everything has to be `Sync`,
    hence we replace `RefCell` with `RwLock` and only speak of "interior mutability"
    in the documentation. Since everything happens in `hg-pyo3` behind the GIL,
    there is at this point no reason to use `read()` and `write()` instead of
    respectively `try_read()` and `try_write()`. But PyO3 is aiming to support
    free-threaded Python (without GIL), and `PySharedRef` should therefore
    allow waiting for its inner locks.
    be765f6797cc
    History
    rust-pyo3: initial port of PySharedRef
    Georges Racinet authored
    At this point, we have a full translation, with some tests.
    The tests are high level, demonstrating the case of iterating over
    `HashSet` as a doctest. The assertions are written as Python statements,
    in order not to be obscure and to resist later refactorings.
    The rust-cpython integration tests will be ported in a subsequent changeset.
    
    We find the example of iterating over `HashSet` to be more convincing than
    the iterating over `Vec`, the example provided in rust-cpython, because
    in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and
    an index. This would of course be reimplementing the iterator, but is simple
    enough that it leads the reader to believe that having a reference is the
    problem, whereas the problem is having a reference that is itself enclosed
    in a type with lifetime that can be arbitrary complex. It took us some
    time to remember that subtlety, and hence we reworded the documentation
    to stress that point.
    
    We decided to put this work a separate crate, which makes running `cargo test`
    work for the crate, but not for the entire workspace: the `extension-module`
    feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as
    default and run the tests with `--no-default-feature` in Makefile, hence in CI.
    
    An important difference with rust-cpython is that everything has to be `Sync`,
    hence we replace `RefCell` with `RwLock` and only speak of "interior mutability"
    in the documentation. Since everything happens in `hg-pyo3` behind the GIL,
    there is at this point no reason to use `read()` and `write()` instead of
    respectively `try_read()` and `try_write()`. But PyO3 is aiming to support
    free-threaded Python (without GIL), and `PySharedRef` should therefore
    allow waiting for its inner locks.
This project manages its dependencies using Cargo. Learn more