Skip to content

Conversation

Tpt
Copy link
Contributor

@Tpt Tpt commented Sep 1, 2025

Introduce PyTypeCheck::classinfo_object that returns an object compatible with instance and make use of it.
Remove PyTypeCheck::NAME

Copy link

codspeed-hq bot commented Sep 1, 2025

CodSpeed Performance Report

Merging #5387 will degrade performances by 10.84%

Comparing Tpt:tpt/dynamic-type (01d11e1) with main (6a6ed99)

🎉 Hooray! codspeed-rust just leveled up to 3.0.5!

A heads-up, this is a breaking change and it might affect your current performance baseline a bit. But here's the exciting part - it's packed with new, cool features and promises improved result stability 🥳!
Curious about what's new? Visit our releases page to delve into all the awesome details about this new version.

Summary

❌ 1 regression
✅ 99 untouched

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

Benchmarks breakdown

Benchmark BASE HEAD Change
vec_bytes_from_py_bytearray_small 770 ns 863.6 ns -10.84%

@Tpt Tpt force-pushed the tpt/dynamic-type branch from c459414 to 7b921c9 Compare September 2, 2025 07:53
@Tpt Tpt marked this pull request as ready for review September 2, 2025 07:53
Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for moving this forward. I wonder if we should be concerned by the performance hit? It's not surprising as we're moving work from compile-time to runtime, at the benefit of better accuracy. I wonder if there are ways we can have our cake and eat it too? 🤔

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks very promising! I think there might be a couple other locations to change (see other comment)

... this might lead to some error messages changing in tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are other callsites to change in this file

  • cast and cast_into
  • Borrowed::cast

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly it won't work because they use the PyTypeCheck trait and not the PyTypeInfo trait

Copy link
Contributor Author

@Tpt Tpt Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a quick look at the types implementing PyTypeCheck and not PyTypeInfo. It's

  • datetime types when abi3 is enabled. This can be fixed easily: DateTime: implement PytypeInfo even using the stable ABI #5388
  • protocol-like types (PyCode, PyIterator, PyMapping, PySequence, PyWeakref, PyWeakrefProxy and PyWeakrefReference). My guess is that we might implement PyTypeInfo on them, returning the collections.abs or similar types in type_object_raw impl and using the fast C method in is_type_of

What do you think about it?

Aside: rust-numpy does not implement PyTypeCheck explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#5402 #5403 #5404 remove all explicit implementations of PyTypeCheck except the ones on PyWeakrefProxy and PyWeakref. Both of them do not have immediate Python equivalents at my knowledge

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added PyTypeCheck::classinfo_object that provides a workaround

impl<'a, 'py> DowncastError<'a, 'py> {
/// Create a new `PyDowncastError` representing a failure to convert the object
/// `from` into the type named in `to`.
pub fn new(from: &'a Bound<'py, PyAny>, to: impl Into<Cow<'static, str>>) -> Self {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DowncastError::new and DowncastIntoError::new are unused now. Do we want to replace the second parameter with a Bound<'py, PyAny>?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should leave this for the moment, as public API. We might want to re-name / re-introduce this as CastError, and if so, we could "fix" the API and deprecate this one at the same time.

@Tpt Tpt force-pushed the tpt/dynamic-type branch 2 times, most recently from 062a32f to dd0d5c5 Compare September 5, 2025 09:11
Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is looking great, the improved error messages make me very happy! I think let's just make this land slightly softer for users with a deprecation, I don't think we need the immediate removal.

Comment on lines 89 to 90
/// Name of self. This is used in error messages, for example.
const NAME: &'static str;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this #[deprecated] instead of removing? The deprecation message can recommend users get a "name" at runtime from classinfo_object, perhaps.

(We might be able to default it to empty, so that users don't need to implement it, we might want to leave existing implementations in PyO3 for a couple of versions just in case users are depending on it.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 6a9135f. This is indeed used by a few repos on GitHub. I added a longer deprecation message because most of them are doing their own version of cast.

@Tpt
Copy link
Contributor Author

Tpt commented Sep 8, 2025

With this MR all remaining usages of PyTypeInfo::NAME and PyTypeInfo::MODULE are bounded by PyClass.

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic, thank you!

@davidhewitt davidhewitt added this pull request to the merge queue Sep 14, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 14, 2025
@Tpt
Copy link
Contributor Author

Tpt commented Sep 15, 2025

@davidhewitt Thank you! f5fbe62 should fix the CI (the type name is different in 3.9)

auto-merge was automatically disabled September 22, 2025 10:09

Head branch was pushed to by a user without write access

@Tpt
Copy link
Contributor Author

Tpt commented Sep 22, 2025

Rebase done: 1963b29

# Conflicts:
#	src/types/sequence.rs
@davidhewitt davidhewitt added this pull request to the merge queue Sep 27, 2025
Merged via the queue into PyO3:main with commit 28db16c Sep 27, 2025
40 of 43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants