replace PyTryFrom by splitting PyTypeInfo

[davidhewitt]

This is a proposed resolution to #3516 and overall I think a positive incremental cleanup to our traits setup.

This PR splits PyTypeInfo into three traits:

• HasPyGilRef, which can be removed in the near future when we get rid of the GIL refs, but will be useful in the short term. It defines the AsRefTarget associated type.
• PyTypeCheck, which is used for types like PyIterator, PySequence, and PyMapping, as these can't implement PyTypeInfo as they don't have concrete type objects.
• PyTypeInfo, which retains its existing API.

This then removes PyO3's internal dependency on PyTryFrom:

• PyAny::downcast() and PyAnyMethods::downcast use PyTypeCheck.
• PyAny::downcast_exact() and PyAnyMethods::downcast_exact to use PyTypeInfo.
• PyAny::downcast_unchecked() uses HasPyGilRef. (PyAnyMethods::downcast_unchecked needs no helper trait.)

From my experience playing around with #3382, e.g. in #3531, having this adjustment makes it much easier to work with PyIterator, PySequence, and PyMapping in code which is migrating between the two APIs.

[davidhewitt]

These special cases for PyIterator etc are no longer needed, because as_ref() and into_ref() are made available by the HasPyGilRef implementation for all T: HasPyGilRef.

[davidhewitt]

This is an example of where this adjustment simplifies interchange between the gil-ref and Py2 APIs; there are more cases in #3572 which can be simplified also.

[codspeed-hq]

CodSpeed Performance Report

Merging #3600 will improve performances by ×2.2

_{Comparing davidhewitt:pytypecheck (ed87637) with main (93370d9)}

Summary

⚡ 1 improvements
✅ 77 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	davidhewitt:pytypecheck	Change
⚡	list_via_extract	273.9 ns	126.1 ns	×2.2

[adamreichold]

This seems unrelated am I am not sure it is a universally good idea. For example, what about downcast chains to identify the correct type? We steer users towards downcasting instead of extracting primarily since constructing PyDowncastError is cheaper than PyErr and this could affect this.

I am not saying this should never happen, just that I would prefer this a separate change with some measurements and discussion on its impact on reasonable code patterns.

[davidhewitt]

Agreed this was probably unnecessary, I'll revert and confirm that codspeed still thinks the diff is fine. I think the inline hints had a much greater effect than this.

I noticed recently that #[cold] doesn't prevent inlining and PGO is likely to do better than manual branch hints, so I suspect we should rarely if ever use #[cold] to be honest 👍

[adamreichold]

Colour me confused. What is the difference between is_type_of and is_exact_type_of then?

[davidhewitt]

Ugh sorry this is an error the new documentation is incorrect. Will revert.

[adamreichold]

Some remarks but the change appears fundamentally right to me.

I do wonder whether this needs a migration guide entry but implementors of PyTypeInfo are probably not that common in user code?

[davidhewitt]

Thanks for the review; I will fixup all points hopefully tomorrow. I think also there is no harm in a small migration note, we can state in it that most users will not care about the difference, though it may affect imports occasionally I guess.

[davidhewitt]

Codspeed seems fine after removing #[cold], and the only other changes since review are docs changes so I'll proceed to merge this and rebase other stuff.