0.19 Release

[davidhewitt]

As discussed in #2593 (comment) let's put out 0.19 release soon and then make MSRV bump breaking changes to ease the pain with CI.

As usual, list of a few things which I was hoping to round off before the release:

• I'd like to finish Rework PyAny::is_instance_of for performance #2881, as I've had a few people ask me about performance of instance checking (e.g. What is the fastest way to get a type identifier in pyo3 #3104)
• In conversation with @adriangb it was reported that #[pyclass(extends = PyBaseException)] doesn't compile without the unsendable option, though I haven't investigated this (sounds like a bug).
• I think PyCell<T> and Py<T> for #[pyclass(frozen)] struct T should have a method to access &T without needing the GIL. I believe this is safe and will help us make progress to nogil / sub-interpreter support (by encouraging use of frozen pyclasses which can then use Rust synchronization mechanisms).
• I wanted to add PyNotImplemented, PyEllipsis and PyNone singleton types: add Ellipsis() and is_ellipsis() methods #2911 (comment) Parked for now as Add types for None, Ellipsis and NotImplemented #3162, see 0.19 Release #3154 (comment)
• I suggested I would implement #[new] which is also a #[classmethod] #3077, although it may be better to postpone this to 0.20 now (sorry!)
• Prevent dropping unsendable classes on other threads Prevent dropping unsendable classes on other threads. #3176
• Avoid acquiring the GIL during __traverse__ Do not apply deferred ref count updates and prevent the GIL from being acquired inside of __traverse__ implementations. #3168 Additional tests for #3168 #3175

[adamreichold]

I think PyCell and Py for #[pyclass(frozen)] struct T should have a method to access &T without needing the GIL. I believe this is safe and will help us make progress to nogil / sub-interpreter support (by encouraging use of frozen pyclasses which can then use Rust synchronization mechanisms).

I think this would require an additional T: Send + Sync bound though, wouldn't it? Py<T> is unconditionally Send + Sync and even a #[pyclass(frozen)] could contain types like Rc or RefCell, couldn't it?

[adriangb]

Sorry for giving you so many problems. Let me at least look into the PyBaseException thing.

[davidhewitt]

I think this would require an additional T: Send + Sync bound though, wouldn't it? Py is unconditionally Send + Sync and even a #[pyclass(frozen)] could contain types like Rc or RefCell, couldn't it?

Good point. I think Sync may be enough to allow &T from multiple threads? The drop requirements for Send are protected by unsendable.

[davidhewitt]

Sorry for giving you so many problems. Let me at least look into the PyBaseException thing.

No problem; I think hopefully that one's not too hard once I see the compiler's full output!

[davidhewitt]

Sorry for giving you so many problems. Let me at least look into the PyBaseException thing.

No problem; I think hopefully that one's not too hard once I see the compiler's full output!

Ok I tried to reproduce just now and couldn't, so I'm marking that one off until you can share a minimal repro @adriangb 😄

[davidhewitt]

For Ellipsis / None / NotImplemented I've decided I'd prefer not rush to add these now, because fixing #1056 might yet adjust our object model and in the meanwhile we can think about their API. I've left #3162 to remember this for later.

[davidhewitt]

@DataTriny I wonder if we think it's possible to release 0.19 with the new license, or whether the final few contributors will take long enough that we should hope to release that with 0.20?

[adamreichold]

@davidhewitt I would like to nominate including #3165 in this release if solution in #3168 turns out to be workable. Otherwise we might have to wait for another chance for a breaking change before fixing this.

If my understanding of the issue is correct, we should also definitely include #3169 to avoid releasing Py::get and PyCell::get with incorrect trait bounds.

[DataTriny]

@davidhewitt I've now contacted everyone and will wait two weeks before sending reminders. We'd be lucky if the relicensing is done before the end of June.

So not ready for 0.19 I guess.

[adamreichold]

If my understanding of the issue is correct, we should also definitely include #3169 to avoid releasing Py::get and PyCell::get with incorrect trait bounds.

So while that one was a dud, I think we should nevertheless include the fix for the unrelated issue #3176 discovered during the discussion.

[adamreichold]

I think that if tonight's remaining merge trains land, we are ready to create a 0.19 release before the purge the MSRV bump. 🤪

[davidhewitt]

Agreed, I'm happy to cut this tomorrow evening unless you're particularly wanting to do it @adamreichold

[adamreichold]

Not particularly, I would like to focus on the follow-up NumPy release (admittedly a smaller endeavour, but I would like follow up in a timely manner).