deprecate IntoPy in favor or IntoPyObject

[Icxolu]

This deprecates IntoPy in favor of IntoPyObject. There are 3 blockers left:

• What do we do with IntoPy::type_output from feature = "experimental-inspect"? Do we just transfer it onto IntoPyObject? move IntoPy::type_output to IntoPyObject::type_output #4657
• The call family of methods still use IntoPy for the vectorcall enhancement of Use vectorcall (where possible) when calling Python functions #4456. The plan was to split this out into some PyCallArgs trait. Maybe we want to target 0.24 for that and revert to the simple approach for now? migrate call API to IntoPyObject #4653
• PyErrArguments has a blanket for IntoPy<PyAny> which we probably should migrate to IntoPyObject. Its method should probably become fallible, but maybe we can just unwrap there for now and tackle this in a later release (maybe along side with "lazy" state of PyErr ... has challenges #4584) switch PyErrArguments blanket impl to IntoPyObject #4660

[davidhewitt]

Thanks for getting on with the first two points already.

PyErrArguments has a blanket for IntoPy<PyAny> which we probably should migrate to IntoPyObject.

Agreed, I think we can just make that change and leave it infallible for now 👍

To avoid chance of racing, can I leave that PR for you to complete? I think it shouldn't conflict with the other error changes I'm working on in e.g. #4655 and later PRs...

[Icxolu]

To avoid chance of racing, can I leave that PR for you to complete?

Sure, I opened #4660 with that.

[davidhewitt]

Thanks, this looks good to me!

I still see a lot of .map(BoundObject::into_any) and the like, I suspect we will add an IntoPyObjectExt trait with some methods like .into_pyresult_pyobject(). That is probably something to follow up after 0.23 at this point.

[davidhewitt]

Does this work to get to PyObject? It might be a touch simpler for users to understand.

Suggested change

	CompareOp::Eq => Ok((self.0 == other.0).into_pyobject(py)?.into_any()),
	CompareOp::Eq => Ok((self.0 == other.0).into_pyobject(py)?.into()),

[Icxolu]

No, currently it does not.

[davidhewitt]

I think interestingly #4593 might help here. But again an improvement for after 0.23

[Icxolu]

Thanks for the review 🚀

I still see a lot of .map(BoundObject::into_any) and the like, I suspect we will add an IntoPyObjectExt trait with some methods like .into_pyresult_pyobject(). That is probably something to follow up after 0.23 at this point.

Yeah, in generic code this comes up a lot. A IntoPyObjectExt could be nice if we can find good names for the methods. I agree that we can postpone this to after 0.23.

[Icxolu]

No, currently it does not.

[codspeed-hq]

CodSpeed Performance Report

Merging #4618 will improve performances by 15.84%

_{Comparing Icxolu:deprecate/into-py (593a479) with main (2d3bdc0)}

Summary

⚡ 5 improvements
✅ 78 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	Icxolu:deprecate/into-py	Change
⚡	test_empty_class_init_py	15.3 µs	13.9 µs	+10.15%
⚡	test_args_kwargs_py	21.1 µs	18.5 µs	+14.27%
⚡	test_args_kwargs_rs	15.8 µs	13.6 µs	+15.84%
⚡	test_simple_kwargs_py	22.3 µs	20 µs	+11.82%
⚡	test_simple_kwargs_rs	21.6 µs	18.8 µs	+14.76%