Implement ToPyObject for Box<T>

[erikjohnston]

There are implementations for &T, Vec<T> etc, so I think it makes sense to also do for Box<T>. I'm also happy to add implementations for Arc etc?

The motivation here is to be able to use Box<str> more easily (as its got slightly less memory overhead than String)

I'm not sure if it makes sense to also implement IntoPy, as it's just doing the same as ToPyObject. Happy to remove it.

Note also that adding I couldn't add an implementation for FromPyObject as I got a "conflicting implementation" error:

note: downstream crates may implement trait pyclass::PyClass for type std::boxed::Box<_>

I confess I don't understand why this is a problem for Box<_> and not for Option<_>.

[codspeed-hq]

CodSpeed Performance Report

Merging #3729 will degrade performances by 11.41%

_{Comparing erikjohnston:erikj/add_box (6497b10) with main (4b17287)}

Summary

❌ 1 regressions
✅ 77 untouched benchmarks

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

Benchmarks breakdown

	Benchmark	main	erikjohnston:erikj/add_box	Change
❌	extract_str_extract_success	647.2 ns	730.6 ns	-11.41%

[davidhewitt]

Thanks for the PR! There is some prior discussion in #3014 where we decided to pause on adding Box support for now; it might be worth having a read of that thread and also elaborating on your use case. We also spoke about Arc<T> in that thread.

[erikjohnston]

The fact that I need to specifically annotate the type of obj here makes me suspicious that implementing IntoPy like above is doing something funky.

[erikjohnston]

Thanks for the PR! There is some prior discussion in #3014 where we decided to pause on adding Box support for now; it might be worth having a read of that thread and also elaborating on your use case. We also spoke about Arc<T> in that thread.

Aha, thanks for the pointer to the PR. It seemed odd that this hadn't come up before, but failed to find any issues about it.

My main use case for using Box<_> is reducing memory footprint:

1. The Box<str> for example is only 16 bytes rather than the 24 bytes for a String.
2. Inside enums when the variants are different sizes, e.g. enum Foo { Bar, Baz(Box<MyHugeStruct>) }.

And then when trying to return such things to Python often requires suitable derefs etc. TBH this isn't the end of the world once the code has been written, its just a little bit of a pain to get it right when writing it (especially when converting from String to Box<str>).

RE the discussion on the PR: I understand that Arc has some special semantics and so doing the easy thing is likely a foot gun. I don't really understand the issue with Box though, as the semantics of ToPyObject is to essentially clone the field into a python object. IntoPy is a similar story I think, if you can convert T why not Box<T>? However, this is not an opinion I hold strongly, and defer to other people's experience of actual uses.

This PR is really just making things slightly more ergonomic for a fairly niche use case, so I'm more than happy if this is something we want to hold back from doing right now.

[davidhewitt]

Thanks for the understanding. I think for now I will close this, but I've added a reminder in #1089 to come back to these implementations once that design question is solved.