Implement new API for PyNone #3684

[snuderl]

Add get_bound method to PyNone and deprecate existing one.

[davidhewitt]

Thank you for joining in with our implementation of the new API! I've been wondering a bit about what to do with PyNone (and similar for PyNotImplemented and PyEllipsis, though we can save them for a future PR). I've written some comments below which might be a sensible way for us to migrate PyNone while taking care not to break users too much. What do you think of those suggestions?

[snuderl]

Thank you for joining in with our implementation of the new API! I've been wondering a bit about what to do with PyNone (and similar for PyNotImplemented and PyEllipsis, though we can save them for a future PR). I've written some comments below which might be a sensible way for us to migrate PyNone while taking care not to break users too much. What do you think of those suggestions?

Hey @davidhewitt .

You managed to pick this up before I even had a chance to pull up the full PR :) I first wanted to just see the CI run and see what is red.

I totally agree about the breaking changes and will add new methods instead.

[davidhewitt]

No problem, I could see you were still working on it, I just hoped that you might be spared some of the CI pain if I put some ideas down regarding the breaking bits!

[codspeed-hq]

CodSpeed Performance Report

Merging #3793 will degrade performances by 19.44%

_{Comparing snuderl:PyNone-new-api (eca943e) with main (975f182)}

Summary

⚡ 1 improvements
❌ 1 regressions
✅ 77 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	snuderl:PyNone-new-api	Change
❌	drop_many_objects	55.3 µs	68.6 µs	-19.44%
⚡	not_a_list_via_downcast	270.6 ns	242.8 ns	+11.44%

[snuderl]

Well not breaking any public api's indeed does end up being much simpler :)

This is probably everything assuming we will wait with migrating the public api for a future version

[davidhewitt]

Thank you, this looks good to me! Yes, in particular PyNone::get() is probably used a lot less than py.None(), so staying away from changing py.None() seems like a very good idea for now 😂

Would you be interested in doing similar PRs for PyNotImplemented and PyEllipsis? Those singletons work in exactly the same way as PyNone.