Revamp PyType name functions to match PEP 737

[aneeshusa]

PyType::name uses tp_name, which is not consistent.
PEP 737 adds a new path forward,
so update PyType::name and add PyType::{module,fully_qualified_name}
to match the PEP.

Thank you for contributing to PyO3!

By submitting these contributions you agree for them to be dual-licensed under PyO3's MIT OR Apache-2.0 license.

Please consider adding the following to your pull request:

• an entry for this PR in newsfragments - see [https://pyo3.rs/main/contributing.html#documenting-changes]
  • or start the PR title with docs: if this is a docs-only change to skip the check
• docs to all new functions and / or detail in the guide
• tests for all new or changed functions

PyO3's CI pipeline will check your pull request, thus make sure you have checked the Contributing.md guidelines. To run most of its tests
locally, you can run nox. See nox --list-sessions
for a list of supported actions.

[aneeshusa]

Closes #4055 and #4056. Thanks @davidhewitt for helping me with this at PyCon sprints today!

[davidhewitt]

Thanks for working on this yesterday! Overall these implementations look nice and tidy (I guess not a huge surprise given we're now better aligned with CPython) so that further convinces me that this is definitely the right approach.

It looks like the pipeline has hit some compile failures elsewhere in the codebase due to the change from Cow<str> to String. Those should hopefully be easy enough to locate and fix.

It would also be really great to add a section to migration.md to explain the PyType::name() change, please.

[aneeshusa]

Thanks for the review, would love help with a few of the CI failures.

[davidhewitt]

Thanks! I'd love to ship this in 0.22 which I'll prep soon; would it be helpful if I pushed a commit to adjust the CI edge cases?

[davidhewitt]

I pushed a couple of commits; the last one makes these functions return Bound<'py, PyString>, which I think is correct for efficiency now that all these variables already exist in the interpreter as Python strings. However to make interface changes less breaking for users I think I'd like to start with a related PR which will add comparisons and other conveniences to Bound<'py, PyString>.

[davidhewitt]

Pushed that to #4245

[davidhewitt]

I think hopefully this is now ready to merge! I'm quite happy with how this has worked out :)

[davidhewitt]

Before proceeding to merge, I'd love to hear other maintainers' opinions on the choice to change these functions to return Bound<'py, PyString>.

I think it is correct from an efficiency perspective, avoiding needless extra conversion to Rust strings in all cases except the pre-3.13 implementation of fully_qualified_name where we occasionally go the other way and build a Python string from a Rust string.

[aneeshusa]

Thanks for the help David, this ended up being more complicated than I expected so I appreciate you fixing all the new compile errors that showed up after I addressed the initial ones. Looking forward to this being merged!

[davidhewitt]

No problem, thanks for getting this one moving! It turned into one of those PRs where as I was adjusting things it spawned new ideas how to simplify and (hopefully) reach a better end result!

[davidhewitt]

If nobody raises objections before Sunday, I'll probably merge this one as-is and then proceed with publishing 0.22. 🚀

[alex]

This looks good to me.