fill PyTypeInfo::NAME with Pythonic values (e.g. BaseException) instead of C ones (e.g. PyBaseException)

[Tpt]

No description provided.

[Tpt]

Not sure if we should set "builtins" there.

[davidhewitt]

Hmm. It seems sorta useless but maybe could have unexpected effects removing, what was the motivation to remove?

[Tpt]

No real motivation at the moment. Added back. See also #5364 for an aside related to this topic.

[davidhewitt]

Thanks, overall makes the error messages look much better IMO and I guess gives us opportunities to clean other stuff up 🤞

[davidhewitt]

Hmm. It seems sorta useless but maybe could have unexpected effects removing, what was the motivation to remove?

[davidhewitt]

Thanks, generally I think this looks great. A few questions / final adjustments.

I wonder if, for sake of not breaking users, we should consider deprecating NAME and just having FULLY_QUALIFIED_NAME, if we can make that work. Otherwise, I think we'd want to mention this in the migration guide.

[davidhewitt]

With #5387 merging, I wonder, is the solution now to deprecate PyTypeInfo::NAME instead (and instead use the TypeHint struct from #5438)?

[Tpt]

With #5387 merging, I wonder, is the solution now to deprecate PyTypeInfo::NAME instead (and instead use the TypeHint struct from #5438)?

Yes! I think this MR is still relevant: we will just concatenate the module name and the type name to generate the TypeHint struct (note that it will also require converting all module=Some("builtins") into module=None but it's not a big deal, the MODULE constant is not used anywhere in pyO3 outside of pyclasses)