release: 0.16.0

[davidhewitt]

Release branch for 0.16.0 release.

There's a couple PRs which I'd like to let merge (and rebase on) before this goes live:

• pyproto: deprecate protocol traits #2173
• Use addr_of_mut in pyo3-ffi #2172
• Implement Auto trait #2165
• Add examples for object and numeric protocols #2156

Hopefully we can have this ready to go live around the weekend at the end of the month (26th./ 27th Feb).

[davidhewitt]

Rebased. I think this is on track to go out at the weekend.

It would be nice if #2175 and #2183 are able to be merged before the release goes out.

I'll hopefully merge #2143 this morning as soon as CI passes.

[davidhewitt]

Rebased one final time. I'll put this live tomorrow evening.

I might rebase to include #2187 if that merges, however I also think it's fine if that lands as part of whatever release follows 0.16.

[birkenfeld]

I just switched a codebase to main and had a small snag: I was defining pymodules in Rust-submodules and got:

error[E0425]: cannot find value `__PYO3_PYMODULE_DEF_REMOTE` in this scope
  --> src/lib.rs:15:19
   |
15 |     m.add_wrapped(wrap_pymodule!(remote))
   |                   ^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
   |
note: static `crate::remote::__PYO3_PYMODULE_DEF_REMOTE` exists but is inaccessible
  --> src/remote.rs:12:1
   |
12 | #[pymodule]
   | ^^^^^^^^^^^ not accessible
   = note: this error originates in the macro `wrap_pymodule` (in Nightly builds, run with -Z macro-backtrace for more info)

The problem being that the #[pymodule] fn was not declared pub. This seems to have been unproblematic in 0.15, but 0.16 transfers the function visibility to the module-def (which is a good thing!)

Is it worth writing a migration entry for this?

[mejrs]

Sorry for being a bit late but I thought about examples for the gc and buffer protocols and noticed a couple things that need fixing before 0.16

• pyproto feature is not documented in lib.rs
• The pyproto feature must be activated to implement __traverse__ in #[pymethods]. The following does not work:

[dependencies]
pyo3 = {path = "../pyo3", default-features = false, features = ["macros"]}

use pyo3::prelude::*;
use pyo3::PyTraverseError;
use pyo3::PyVisit;

#[pyclass]
struct Thing;

#[pymethods]
impl Thing {
    fn __traverse__(&self, _visit: PyVisit) -> Result<(), PyTraverseError> {
        Ok(())
    }

    fn __clear__(&mut self) {
    }
}

results in:

error[E0432]: unresolved import `pyo3::PyTraverseError`
 --> src\lib.rs:2:5
  |
2 | use pyo3::PyTraverseError;
  |     ^^^^^^^^^^^^^^^^^^^^^ no `PyTraverseError` in the root

error[E0432]: unresolved import `pyo3::PyVisit`
 --> src\lib.rs:3:5
  |
3 | use pyo3::PyVisit;
  |     ^^^^^^^^^^^^^ no `PyVisit` in the root

error[E0433]: failed to resolve: could not find `gc` in `class`
 --> src\lib.rs:8:1
  |
8 | #[pymethods]
  | ^^^^^^^^^^^^ could not find `gc` in `class`
  |
  = note: this error originates in the attribute macro `pymethods` (in Nightly builds, run with -Z macro-backtrace for more info)

because the pyproto feature must be enabled for those imports.

• Are/should be the __getbuffer__/__releasebuffer__ method be unsafe to implement, rather than just unsafe to call?

[davidhewitt]

Ah, thanks both. I've got a moment of calm this evening so I'll push a fix for these points shortly.

Are/should be the __getbuffer__/__releasebuffer__ method be unsafe to implement, rather than just unsafe to call?

@mejrs can you elaborate on this point a little? We require the user to use unsafe keyword in the implementation, are you thinking we should do something different?

[mejrs]

A trait can be unsafe to implement and unsafe to call. For example stds Allocator. dealloc is unsafe because the caller has to provide a valid pointer and allocate is unsafe on behalf of the implementer, because the caller has to trust the implementer that the returned pointers are valid.

So my question is, is the buffer protocol also like that? Fwiw I am fine with "the user has to type an unsafe keyword somewhere, that is enough and nothing needs to change".

But for example we can have unsafe pymethod blocks...

#[pymethods]
unsafe impl Foo {}

...if the macro removes the unsafe keyword from the tokenstream

[mejrs]

To clarify I am not saying that this needs to change, just that we might want to make a decision on it.

[davidhewitt]

👍 I think making a decision on any change there is probably too much just before the release. We can always reconsider and make tweaks for a future release.

unsafe pymethod blocks

that's a really interesting idea. I think that while multiple-pymethods is dependent on inventory which isn't universally supported, I'd rather not go down that road. In the future, it could definitely make sense.

(EDIT fat fingers sent early!)

[davidhewitt]

Rebased to pick up #2192, this is now the version I expect to put live this evening.

[davidhewitt]

Release is live 🎉