0.20 release

[davidhewitt]

Debian bookworm was released a week ago now, so we're able to release 0.20 whenever suits us and send the MSRV bump downstream. I don't think there's pressure to release right away, so here's a list of proposal of items I'd hope to ship in this release.

Given the new support for __eq__ and the discussions around __next__ / __anext__, I think it would be nice thematically to push a group of improvements to protocol methods in 0.20. Namely, I'm aware of possible changes to:

• __del__ - pymethods: add support for __del__ #2484 and also a GC bug ResourceWarning: Object of type XXX is not untracked before destruction #3064 which I think both require a rework to our tp_dealloc
• __next__ and __anext__ - possible redesign as discussed in __anext__ should be able to return &PyAny #3190
• #[new] (i.e. __new__) - Allow #[new] to return existing objects #2384
• __buffer__ and __release_buffer__ - PEP 688 buffer methods #3148

I've ordered these by my own opinion of their priority (which will differ for others). I'd like to aim to implement these in the same order over the next few weeks, and then prepare the release.

If anyone would like to see other items in the release, or to release sooner without these, please comment. Similarly if anyone wants to own the implementation for anything listed here, feel free to stake your claim so that we don't accidentally push over each other 😄

Other possible items (from discussion below):

• Enable comparison of C-like enums by identity #3061
• AsPyPointer should be unsafe trait #3325

[adamreichold]

I would like to nominate completing the license change for the 0.20 release.

[alex]

#3061 would be great, if it's close to getting over the edge.

[davidhewitt]

I think that'll be subject to the outcome of #2384

[orowith2os]

Also worth mentioning #3268.

[davidhewitt]

It would be awesome to have #3268 but realistically that's beyond the capacity I can offer, so unless others are interested in taking that on I won't be pushing that for this release. (I can help design / mentor.)

[davidhewitt]

Some resolution / mitigation for #3325 would be desirable, I'll add to the OP.

[davidhewitt]

As the changes for #3325 have the potential for quite a few edge cases which will cause disruption to user code, and we have quite a lot already merged waiting to release, I'm wondering about switching priorities up and just helping get #3325 resolved and then cutting a release.

We also have a plan for the new higher-performance API in #3382 which I think is both quite a lot of work and also likely to yield some great improvements, so I'm quite keen to get on with the 0.21 release cycle.

The rest of the trait changes for __next__, __anext__ etc can land in 0.21 if they're not too breaking, else maybe they're better to land in 0.22 once the dust has settled from the API rework.

Any objections? :)

[alex]

This is fine by me! I'm not going to get back to working on that PR until next week. I also think that if we're not able to remove the usage of AsPyPointer entirely, marking it unsafe is a fine idea.

…

On Sat, Aug 19, 2023, 8:14 AM David Hewitt ***@***.***> wrote: As the changes for #3325 <#3325> have the potential for quite a few edge cases which will cause disruption to user code, and we have quite a lot already merged waiting to release, I'm wondering about switching priorities up and just helping get #3325 <#3325> resolved and then cutting a release. We also have a plan for the new higher-performance API in #3382 <#3382> which I think is both quite a lot of work and also likely to yield some great improvements, so I'm quite keen to get on with the 0.21 release cycle. The rest of the trait changes for __next__, __anext__ etc can land in 0.21 if they're not too breaking, else maybe they're better to land in 0.22 once the dust has settled from the API rework. Any objections? :) — Reply to this email directly, view it on GitHub <#3246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBGBXD2FSYVYV5NSMP3XWCUZFANCNFSM6AAAAAAZI2FQOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[davidhewitt]

As far as I'm currently thinking, I think once the following are reviewed / reworked / merged I will create a release PR:

• relax multiple-import check to only prevent subinterpreters #3446
• also use PyErr::SetObject on Python versions before 3.12 #3455
• truncate leap seconds on chrono to datetime conversions #3458

(All three close bugs which require small API adjustments to resolve.)